Every ITSM migration checklist ANZ teams rely on starts with the same good intentions. Then go-live day arrives and something that was never on the list becomes the thing that nearly derails the whole project. Most go-live surprises are not surprises at all. They are predictable problems that occur when specific preparation steps get rushed, skipped, or assumed.
The teams that complete ITSM migrations without major incidents are more thorough in the phases nobody talks about. This checklist covers every phase from discovery to post-launch stabilisation, with the specific items that determine whether a migration succeeds or stalls.
Migration already in flight and seeing gaps? Book a diagnostic call and we will identify the highest-risk gaps and what to address before go-live.
Three Myths That Get ANZ Teams Into Trouble Before Migration Begins
Myth 1: The Vendor Implementation Guide Covers Everything
Vendor implementation guides are excellent for platform configuration. They tell you how to set up the tool. They do not tell you how to document your current-state processes, how to assess your data quality, or how to design a training programme for process change rather than tool mechanics. Those gaps are yours to fill.
Myth 2: Ticking Every Box Means a Successful Migration
Ticking boxes is not the same as doing the work. A data audit checkbox ticked after a 30-minute review is not a data audit. A training session delivered the week before go-live is not a training programme. The checklist is only as valuable as the rigour applied to each item.
Myth 3: Go-Live Is the Finish Line
Most migration plans end at go-live. The 30, 60, and 90 days after launch are where adoption either takes hold or collapses. According to Salesforce ITSM migration research, successful migrations design the post-launch adoption phase before go-live, not after. This checklist includes it.
The planning gap
Research from Kaopiz Software found that 65% of failed migration projects spent less than 20% of their total timeline on planning. In other words, the projects that fail spend the most time on implementation and the least time on the preparation that determines whether the implementation succeeds.
The Complete ITSM Migration Checklist ANZ Teams Should Follow
This checklist is structured around six phases every mid-market migration moves through. Each phase builds on the previous one. Skipping ahead creates compounding risk.
Phase 1: Discovery and Current-State Assessment
This is the phase most teams underinvest in. Allocate 20 to 25% of the total project timeline here. Every subsequent phase becomes easier when this one is done properly.
- Document all current ITSM workflows including ticket flow, approvals, categories, and escalation paths
- Interview frontline agents and service desk managers about what the current system actually does versus what it is supposed to do
- Identify all informal workarounds agents have built over time — these are undocumented processes that will break on go-live day if not captured
- Map every integration with a named owner for each: monitoring tools, HRIS, asset management, communication platforms
- Run a full data audit covering duplicate records, inconsistent ticket categorisation, orphaned assets, and outdated user accounts
- Make a deliberate decision on historic data: what migrates, what gets archived, what gets deleted
- Capture current baseline KPIs: MTTR, FCR rate, SLA adherence, and ticket volume by category
- Define what success looks like in measurable terms before any vendor conversations begin
The teams that complete ITSM migrations without major incidents are more thorough in the phases nobody talks about. Discovery is the phase nobody talks about.
Phase 2: Platform Selection and Project Governance
- Evaluate platforms against your documented requirements, not a generic feature grid
- Test shortlisted platforms against your actual workflows, not vendor demo scenarios
- Assess total cost of ownership including implementation, licensing, training, and ongoing support
- Confirm ANZ-specific support availability if your team operates outside US or UK business hours
- Name an executive sponsor with genuine decision-making authority, not just a title on the project plan
- Form a cross-functional migration team covering IT, HR, key business departments, and a named project lead
- Define the escalation path for scope, budget, and timeline disputes in writing before the project starts
- Set the cadence for project reviews: weekly team standups and fortnightly executive sponsor check-ins
Phase 3: Configuration and Data Migration
This is where most teams spend the majority of their project time. The temptation is to replicate the old system exactly. Resist it. Migration is the right moment to simplify.
- Configure core processes first: incident management, service request, and change management
- Accept out-of-the-box configuration wherever possible before customising
- Redesign workflows to remove manual steps rather than replicating them in the new system
- Clean data before migration, not after — migrating dirty data into a clean system produces a dirty system faster
- Test every integration in a non-production environment before the cutover window
- Configure SLA rules, escalation triggers, and notification templates
- Build and populate the knowledge base before go-live
- Set up reporting dashboards so KPIs are visible from day one of operation
Phase 4: Testing and Go-Live Readiness
Testing is where most migrations cut corners to recover lost time. This is the worst place to cut. If the schedule slips, extend the go-live date rather than the testing window.
- Allocate 25 to 30% of total project time to testing
- Run user acceptance testing with actual service desk agents, not just the project team
- Test every workflow end-to-end including edge cases and exception paths
- Test all integrations under realistic load conditions
- Verify data migration accuracy by spot-checking migrated records against source data
- Document and resolve all UAT issues before setting a go-live date
- Build and test a rollback plan before cutover begins
- Complete a go-live readiness review with the executive sponsor
Phase 5: Training and Change Management
Training is the most consistently underestimated step in any service desk migration. Most plans cover tool training. Almost none cover process change training, and that is what determines adoption.
- Deliver separate training for agents, team leads, and end users
- Include process training alongside tool training: how work flows in the new system, not just how to click the buttons
- Identify migration champions in each team who can support colleagues in the first weeks after go-live
- Create short reference guides agents can use at their desk during the first two weeks
- Communicate the go-live date and what changes to all affected staff at least two weeks before launch
- Set up a real-time feedback channel so agents can flag issues immediately after go-live
Phase 6: Post Go-Live Stabilisation
This phase does not appear on most migration plans. It is arguably the most important for long-term success. Schedule the 30, 60, and 90-day reviews before go-live, not after.
- Assign a named post-launch owner whose primary focus for the first 90 days is adoption
- Track adoption metrics from day one: agent login rates, ticket submission via the new platform, and self-service usage
- Compare post-launch KPIs against the pre-migration baseline captured in Phase 1
- Hold a structured lessons-learned session at 30 days with the full migration team
- Identify and prioritise the top five process improvements surfaced during the first month
- Confirm the legacy system decommission date and communicate it widely
Common ITSM Migration Mistakes That Still Happen
| Mistake | What It Looks Like | How to Prevent It |
|---|---|---|
| Migrating everything | All historical data transferred regardless of quality | Define data migration scope in Phase 1. Archive old data, do not migrate it. |
| Config before discovery | Platform setup begins before workflows are documented | No configuration starts until Phase 1 is signed off by the project sponsor |
| Tool training only | Agents revert to old behaviours within weeks of go-live | Add process training alongside tool training in Phase 5 |
| Late testing | UAT compressed into the final two weeks to recover schedule | Protect testing time. If schedule slips, extend go-live, not testing. |
| No post-launch owner | Project team disbands after go-live and adoption stalls | Name a post-launch owner before go-live. Budget their time for 90 days. |
| Parallel systems too long | Old system stays live for months and agents use whichever is easier | Set a firm legacy decommission date at project kick-off and communicate it widely. |
What a Successful ITSM Migration Looks Like in Practice
The preparation decisions described in this checklist are what separate migrations that deliver lasting value from those that stall or regress. The pattern is consistent across organisations of different sizes and industries: thorough discovery, simplified workflows, and a structured post-launch adoption phase produce outcomes that hold.
Waterstons: 2x ticket volume handled after migrating to Freshservice
Waterstons, a UK-based managed service provider with over 120 business consultants, was running a legacy incident and service management solution that produced high resolution turnaround times and limited functionality. After migrating to Freshservice, the team handled 2x their previous ticket volume, closing 13,007 tickets compared to 6,131 with their old platform. Agent productivity improved, average response and resolution times dropped significantly, and self-service portal adoption increased measurably. The outcome came from the migration approach, not just the platform change. Source: Freshworks customer case study.
Our ITSM Platform Migration service covers this end to end for ANZ mid-market teams. For teams still deciding whether migration is the right call, our ITSM Platform Selection service provides a vendor-neutral evaluation framework before any commitment is made. You can also read our article on ITSM implementation mistakes for the structural preparation decisions that most directly determine whether a migration succeeds.
Migration Already in Flight and Seeing Gaps?
If your migration is already underway and you recognise gaps in this checklist, it is not too late to course-correct. The earlier preparation gaps are addressed, the cheaper they are to fix. KlickFlow works with mid-market ANZ IT teams to review migration plans, identify the highest-risk gaps, and build a prioritised preparation plan before go-live.
Book a 30-minute diagnostic call. We will tell you honestly what is broken, what is not, and what to fix first.
Frequently Asked Questions
For a mid-market organisation of 200 to 2,000 employees, a full migration typically runs four to six months. Discovery should take 20 to 25% of that timeline. Configuration and data migration typically take 30 to 40%. Testing should take 25 to 30%. Post-launch stabilisation runs for 90 days after go-live. Teams that compress discovery and testing to recover schedule consistently produce more expensive post-launch remediation than the time saved was worth.
Migrate all open and in-progress tickets. Migrate closed tickets from the last 12 to 24 months for reporting and trend analysis. Archive anything older rather than migrating it. Delete duplicate records, corrupted data, and inactive user accounts before migration. Cleaning data before migration is significantly easier than cleaning it after, and migrating dirty data into a clean system produces a dirty system faster than most teams expect.
At each phase gate, ask three questions. Is the current phase deliverable fully completed and signed off? Are known risks documented with named owners and mitigation plans? Does the executive sponsor have an accurate picture of progress? If any answer is not clearly yes, the project is at risk. Do not advance to the next phase until all three are confirmed.
Use the vendor checklist as a reference for platform configuration steps. Build your own for everything else: current-state documentation, data quality assessment, change management, training design, and post-launch adoption. The vendor checklist is designed to get their platform live. Your checklist needs to get your organisation ready. These are different objectives and they require different preparation.
Insufficient discovery and underestimated change management. Most ANZ mid-market migrations that fail do so because discovery was compressed to two or three weeks rather than the 20 to 25% of project timeline it requires, and because training covered the tool interface rather than the process changes agents needed to adopt. Both of these are visible in the project plan before go-live and both can be corrected if identified early enough.
Sources
- Salesforce. (2025). ITSM Migration: Why Customers Are Moving On From Legacy Tools.
- InvGate. (2025). ITSM Migration: A Complete 6-Step Guide.
- Freshworks. (2024). Complete Guide to ITSM Implementation.
- Kaopiz Software. (2025). The Hidden Complexity of Data Migration.
- Freshworks. (2024). Waterstons Customer Case Study.