Moving to a new IT service management platform means moving years of tickets full of personal data, pasted passwords and approval history, along with the workflows and integration credentials that decide who gets access to what. ITSM platforms run incident, request, change and problem management, and in most organisations they are also where access requests are approved, where the service desk verifies callers, and where integrations with identity, monitoring and automation tools hold powerful API credentials. A migration, whether to consolidate tools, move to a software as a service platform or change provider, touches all of this at once. This vendor-neutral playbook is for service management, IT operations and security teams who own the move. It covers the data and security inventory, cleaning ticket data before it moves, rebuilding roles and approval workflows, integration credentials, cutover and rollback, and closing the old platform. Securing the platform in steady state is covered in Securing the ITSM platform itself; a first deployment is covered in the ITSM platform rollout playbook.
Key takeaways
- Do not migrate what you would not collect today. Apply retention rules before the move and scan historic tickets and attachments for secrets and sensitive personal data.
- Approval workflows are security controls. Access requests, privileged changes and caller verification steps must be rebuilt and tested, not assumed to carry over.
- Integration tokens are the crown jewels. Issue new, narrowly scoped credentials for every integration and revoke the old ones; an unrotated support platform token has already caused a public breach.
- Keep the audit trail intact. Change and access approval history is evidence for audits and investigations, so preserve it with integrity, whether it moves or is archived.
- Close the old platform deliberately. Read-only first, then export, then confirm deletion with the provider, and remove old inbound email addresses and portals.
What has to move
ISO/IEC 20000-1:2018 frames service management as planning, designing, transitioning, delivering and improving services, and an ITSM migration is itself a transition that needs that discipline. From a security point of view, the inventory looks like this.
| Object | Security concern | Typical decision |
|---|---|---|
| Ticket history and attachments | Personal data, identity documents, screenshots, pasted passwords and keys | Apply retention, scan and redact, migrate only what is needed; archive the rest |
| Change records and approvals | Audit evidence for change management and access decisions | Migrate or archive with integrity checks and access controls |
| Service catalogue and request forms | Forms that trigger access provisioning or privileged actions | Rebuild with explicit approval steps |
| Workflows and business rules | Automated approvals, escalations and scripts with elevated rights | Review every rule that grants access or runs code |
| Roles, groups and agent accounts | Over-privileged administrators and stale accounts | Recreate from current role design through single sign-on |
| Integrations | API keys, OAuth clients and service accounts for identity, monitoring, chat, automation and CMDB tools | Issue new credentials; revoke old ones at cutover |
| Email channels and portals | Inbound mailboxes and public portals that create tickets | Move, then disable old addresses and sites |
| Knowledge base | Articles with internal host names, procedures and sometimes credentials | Review, clean and set visibility before migration |
| CMDB data held in the platform | Asset and relationship data used for incident and change decisions | Reconcile; see Securing the CMDB and asset inventory itself |
Cleaning ticket data before it moves
Service desks collect sensitive information because users paste it in to get help. A migration is the one point at which every historic ticket passes through your hands, so it is the cheapest moment to reduce that exposure.
- Apply retention first: agree retention periods per ticket type with legal and records owners and do not migrate tickets past their period. Under the GDPR, the storage limitation principle in Article 5(1)(e) requires personal data to be kept in identifiable form for no longer than is necessary for the purposes for which it is processed (Regulation (EU) 2016/679).
- Scan for secrets: run secret scanning over ticket bodies, work notes, attachments and knowledge articles. Treat every credential found as exposed: rotate it, then redact it. See the Generic API Key Detection Guide.
- Find identity documents: account recovery and removal requests often include passports and driving licences. Decide whether they need to exist at all after verification is complete.
- Protect the export: bulk exports are a full copy of the service desk. Encrypt them, hold them in a restricted location, give the migration identity access only for the migration window, and destroy staging copies afterwards in line with NIST SP 800-88 Rev. 2.
- Preserve integrity: record counts and hashes of exported records so you can show that change and approval history arrived complete and unaltered.
The Internet Archive breach shows what sits in a support platform: according to the attacker, an unrotated support platform token gave access to more than 800,000 support tickets sent since 2018, and some of those requests included identity documents.
Rebuilding roles and approval workflows
Many security controls live inside ITSM workflows: who approves an access request, whether a privileged change needs a second approver, whether the service desk must verify a caller before a password or MFA reset, and whether emergency changes are reviewed afterwards. Migration tooling copies data; it rarely copies intent.
| Workflow | What can silently break | Test before go-live |
|---|---|---|
| Access requests | Approval step skipped for some catalogue items, or the requester can approve their own request | Submit requests as a user and as the approver; confirm separation of duties |
| Privileged and emergency change | Change advisory or second approval not enforced; emergency changes never reviewed | Raise each change type and confirm the approval path and post-review task |
| Password and MFA reset requests | Caller verification step removed or made optional | Run the reset script end to end; confirm the verification field is mandatory |
| Automated fulfilment | Workflows that call identity or cloud APIs now run with broader credentials | Check which credential each automation uses and its scope |
| Agent and administrator roles | Default administrator roles granted widely during build and never reduced | Export the role assignments and review them before cutover |
The service desk is a frequent social engineering target, so caller verification deserves particular care. The MGM Resorts breach began with a help desk phone call. See the Account Recovery and Help Desk Security Guide and the Help Desk Identity Verification Policy Template, and for change approval design the Change Management Security guide.
Where identity fits: integration credentials and agent access
An ITSM platform is connected to most of the IT estate, and each connection is a non-human identity.
- Inbound integrations: monitoring, security and chat tools create tickets through API keys or OAuth clients. Issue new credentials with create-only scope where the platform allows it.
- Outbound integrations: fulfilment workflows call identity providers, directories and cloud platforms to grant access. These credentials can often create accounts or change group membership, so scope them to the specific actions the workflow performs and store them in a secrets manager.
- Agent sessions: service desk agents open tickets submitted by anyone. The Canvas Instructure breach is a reminder: according to Instructure, a support ticket carrying a stored cross-site scripting payload ran in an agent's authenticated session and yielded an authorisation token with elevated access. Test the new platform's handling of HTML and attachments in tickets before go-live.
- The migration identity: the account or tool that reads the old platform and writes the new one can read every ticket. Make it dedicated, time-limited and logged, and remove it when the migration ends.
For the full integration view, see the ITSM platform integration security guide.
The phased playbook
- Inventory and decide. List data sets, workflows, roles, integrations, email channels and portals, with an owner and a move, rebuild, archive or retire decision for each.
- Build the new instance securely. Single sign-on and MFA for all agents and administrators, role design from current job functions, logging to your SIEM, and restricted administrative access, before any data arrives.
- Clean and export. Apply retention, scan and redact secrets, rotate exposed credentials, and export with counts and hashes.
- Load into a test instance. Validate record counts, attachment integrity and permissions on sensitive ticket types such as HR or security incidents.
- Rebuild and test workflows. Run the workflow tests in the table above, including negative tests for separation of duties.
- Re-create integrations. Issue new credentials per integration; keep old ones valid only until cutover.
- Cutover. Put the old platform into read-only mode, run a final delta load, switch email routing and portal links, and enable integrations on the new platform.
- Rollback window. Keep the old platform read-only and intact for an agreed period. Rollback means re-enabling it and replaying tickets raised in the new platform, so log those carefully during the window.
- Close the old platform. Revoke integration credentials, disable accounts, remove old inbound addresses and portal DNS records, archive what must be retained, and confirm deletion with the provider.
Closing the old platform
A read-only ITSM instance that nobody watches is still a searchable store of tickets and a holder of integration credentials. For a software as a service platform, check the contract for data return and deletion at the end of the service; for processors of personal data, GDPR Article 28(3)(g) requires the processing contract to stipulate that, at the controller's choice, the processor deletes or returns all personal data after the end of the services and deletes existing copies unless EU or Member State law requires storage. NIST CSF 2.0 outcome GV.SC-10 expects supply chain plans to cover activities after a partnership ends. Keep an archive of change and approval records for the period your audit obligations require, with access limited to records and audit staff, and alert on any login to the old instance after cutover.
Decision guidance
| Choice | Option A | Option B | Choose A when |
|---|---|---|---|
| Historic tickets | Migrate all within retention | Migrate open and recent only; archive the rest read-only | Agents genuinely search old tickets daily; B reduces exposure and cost in most cases |
| Workflows | Lift and shift | Redesign from current process | Workflows are documented and recently reviewed |
| Cutover | Single cutover weekend | Phased by team or service line | One service desk and simple integrations; large federated organisations usually need B |
| Archive | Export to a records system | Keep old platform read-only under contract | You want to stop paying for and patching the old platform |
Small organisations: the biggest wins are cleaning secrets out of tickets and making sure caller verification and access approvals survive. Large organisations: expect dozens of integrations and team-specific workflows; maintain an integration register with owners and credential expiry dates, and phase the migration by service line.
Detection and measurement
Forward audit logs from both platforms to the SIEM. Alert on bulk ticket exports, role or workflow changes outside change windows, new integrations or API clients, any use of old integration credentials after cutover, and logins to the old instance once it is read-only.
- Secrets found and rotated: count of credentials found in historic tickets, and percentage rotated before migration (target 100 percent).
- Data minimised: percentage of historic tickets archived or deleted rather than migrated.
- Workflow parity: percentage of security-relevant workflows passing their tests before go-live.
- Integration hygiene: percentage of integrations using new, scoped credentials, and old credentials revoked.
- Record integrity: exported and imported counts and hashes matching for change and approval records.
- Residual access: logins to and API calls against the old platform after cutover (target zero).
Common failure patterns
- Secrets migrated intact: passwords and API keys pasted into old tickets move to the new platform and stay valid.
- Integration tokens never revoked: the old platform's tokens keep working, or the new ones are granted administrator scope for convenience.
- Self-approval: rebuilt access request forms allow requesters to approve their own access.
- Verification step lost: the caller verification field in reset workflows becomes optional during rebuild.
- Old email addresses left live: the previous inbound address still creates tickets in an unmonitored instance or bounces to a reusable domain.
- Audit trail broken: change approvals are imported without approver identities or timestamps, undermining audit evidence.
Framework mapping
| Migration activity | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK |
|---|---|---|---|
| Data inventory and minimisation | CM-8 System Component Inventory | ID.AM-07 | T1213 Data from Information Repositories |
| Workflow and change control | CM-3 Configuration Change Control | PR.PS-01 | |
| Agent roles and approvals | AC-2 Account Management, AC-6 Least Privilege | PR.AA-05 | |
| Integration credentials | IA-5 Authenticator Management | PR.AA-01 | T1528 Steal Application Access Token |
| Logging and incident records | AU-2 Event Logging, AU-11 Audit Record Retention, IR-5 Incident Monitoring | PR.PS-04, DE.CM-09 | |
| Supplier exit and disposal | SA-9 External System Services, MP-6 Media Sanitization | GV.SC-10 |
NIST SP 800-61 Rev. 3 positions incident response within CSF 2.0 risk management; if the ITSM platform holds incident records, plan the migration so incident handling and its evidence are not interrupted.
Practitioner checklist
- Inventory data sets, workflows, roles, integrations, email channels and portals with owners and decisions.
- Apply retention rules before export and archive rather than migrate where possible.
- Scan tickets, attachments and knowledge articles for secrets; rotate before redacting.
- Encrypt and restrict exports; record counts and hashes; destroy staging copies.
- Build the new instance with single sign-on, MFA, least-privilege roles and logging first.
- Test access approval, privileged change and caller verification workflows, including negative cases.
- Issue new scoped credentials for every integration and revoke old ones at cutover.
- Test how the new platform renders HTML and attachments in tickets opened by agents.
- Keep the old platform read-only during the rollback window and alert on any use.
- Remove old inbound addresses and portals, confirm provider deletion and retain audit archives.
Standards and references
- ISO: ISO/IEC 20000-1:2018, Service management system requirements
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
- MITRE ATT&CK: Data from Information Repositories (T1213)
- MITRE ATT&CK: Steal Application Access Token (T1528)
Related NHI Mgmt Group resources: If your ITSM platform is compromised · ITSM platform health check · Security Requirements for Selecting an ITSM and Service Desk Platform · AI Agents in the IT Service Desk