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.
Here is the reality: 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 not luckier than anyone else. They are more thorough in the phases nobody talks about.
This ITSM migration checklist ANZ covers every phase from discovery to post-launch stabilisation. Work through it before your project starts configuration and you will close out the gaps that derail most mid-market migrations.
Three Myths That Get ANZ Teams Into Trouble Before Migration Begins
Before the checklist, it is worth addressing three assumptions that cause teams to under-prepare even when they think they have done the work.
Myth 1: The Vendor’s 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 your 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’s ITSM migration research, successful migrations design the post-launch adoption phase before go-live — not after. This checklist includes it.
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. Research from Kaopiz Software found that 65% of failed migration projects spent less than 20% of their timeline on planning. Invest here and every subsequent phase becomes easier.
- Document all current ITSM workflows including ticket flow, approvals, categories and escalation paths
- Interview frontline agents and service desk managers — not just IT leadership — about what the current system actually does vs 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 now
- Map every integration — monitoring tools, HRIS, asset management, communication platforms — with a named owner for each
- Run a full data audit: identify duplicate records, inconsistent ticket categorisation, orphaned assets, outdated user accounts
- Make a deliberate decision on historic data — what migrates, what gets archived, what gets deleted. Do not default to migrating everything
- Capture current baseline KPIs: MTTR, FCR rate, SLA adherence, ticket volume by category. You need a before picture to prove the after
- Define what success looks like in measurable terms before any vendor conversations begin
Time to allocate: 20 to 25% of your total project timeline. For a five-month migration, that is four to five weeks of discovery before configuration begins.
Phase 2: Platform Selection and Project Governance
Platform selection and governance setup happen in parallel. Neither can wait for the other.
- Evaluate platforms against your documented requirements — not a generic feature grid
- Test shortlisted platforms against your actual workflows, not demo scenarios
- Assess total cost of ownership including implementation, licensing, training and ongoing support — not just licence cost
- 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: IT, HR (for onboarding flows), 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, fortnightly executive sponsor check-ins
Want help evaluating which platform fits your environment? Book a free tool selection assessment with the KlickFlow team.
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, change management. Advanced capabilities come in later phases
- Accept out-of-the-box configuration wherever possible before customising. Most platforms have ITIL-aligned defaults that work well for mid-market teams
- 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 just 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 to match your agreed service commitments
- Build and populate the knowledge base before go-live — agents should not be starting from zero on day one
- Set up reporting dashboards so KPIs are visible from the first day 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. Insufficient testing is one of the clearest predictors of a difficult launch.
- Allocate 25 to 30% of total project time to testing — not 10%
- Run user acceptance testing (UAT) 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 — spot check migrated records against source data
- Document and resolve all UAT issues before setting a go-live date. Do not go live with known defects
- Build and test a rollback plan. If go-live fails, how do you revert? Who makes that call? How quickly?
- Complete a go-live readiness review with the executive sponsor. Every stakeholder confirms green before cutover begins
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. Each audience needs different content
- 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. These are peers 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 — a one-page cheat sheet per process, not a 60-page manual
- 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 rather than working around them silently
Phase 6: Post Go-Live Stabilisation
This phase does not appear on most service platform migration plans. It is arguably the most important for long-term success.
- Schedule 30, 60 and 90-day review points before go-live — not after
- Assign a named post-launch owner — someone whose job for the first 90 days is adoption, not the next project
- Track adoption metrics from day one: agent login rates, ticket submission via new platform, self-service usage
- Compare post-launch KPIs against your pre-migration baseline. Document what improved, what did not, and why
- Hold a structured lessons-learned session at 30 days with the full migration team
- Identify and prioritise the top 5 process improvements surfaced during the first month of operation
- Confirm the legacy system decommission date — do not run parallel systems indefinitely, as this undermines adoption of the new platform
Common ITSM Migration Checklist ANZ Mistakes That Still Happen
Even teams with detailed plans make these mistakes. Worth knowing before you start.
| Mistake | What It Looks Like | How to Prevent It |
|---|---|---|
| Migrating everything | All historical data transferred regardless of quality or relevance | Define your data migration scope in Phase 1. Archive old data, do not migrate it. |
| Config before discovery | Platform setup begins before current workflows are fully documented | No configuration starts until Phase 1 is signed off by the project sponsor |
| Tool training only | Agents know how to use the new platform but revert to old behaviours within weeks | Add process training alongside tool training in Phase 5 |
| Late testing | UAT compressed into the final two weeks to recover schedule | Protect testing time in the project plan. If the schedule slips, extend go-live — not testing. |
| No post-launch owner | Project team disbands after go-live. Adoption problems go unmanaged. | Name a post-launch owner before go-live. Budget their time for 90 days. |
| Parallel systems too long | Old system stays live for months. Agents use whichever is easier. | Set a firm legacy decommission date at project kick-off and communicate it widely. |
What This Approach Looks Like in Practice
A 700-person retail group in Auckland approached KlickFlow after a previous migration partner had delivered a go-live that left the service desk in worse shape than before. Agents were working across two systems. Tickets were being created in both. Leadership had lost confidence in the IT team despite the team doing everything the project plan asked of them.
Working through a structured reset using this ITSM migration checklist ANZ framework, we ran a five-week discovery phase that had been skipped in the original project. We found 22 undocumented workflows, 4,100 duplicate records in the contact database, and a training programme that had covered the platform interface but never addressed how the new escalation process worked.
Within 45 days of the reset go-live, agent adoption was at 96%. Within 90 days, MTTR had dropped by 31% and self-service resolution was running at 48%. None of that required new technology. It required the preparation that had been skipped the first time.
Frequently Asked Questions
How long should each migration phase take for an ANZ mid-market team?
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%. Training and change management run in parallel with the final configuration and testing phases. Post-launch stabilisation runs for 90 days after go-live.
What data should I actually migrate to my new ITSM platform?
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. Do not carry dysfunction into a new system — it is significantly harder to clean data after migration than before.
How do I know if my migration is on track?
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 of these are not clearly yes, the project is at risk. Do not advance to the next phase until they are.
Should I use a vendor’s migration checklist or build my own?
Use the vendor’s 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’s checklist is designed to get their platform live. Your checklist needs to get your organisation ready.
What to Do Next
If your migration is already in flight and you recognise gaps in this checklist, it is not too late to course-correct. The earlier you address preparation gaps, the cheaper they are to fix.
Book a free ITSM migration assessment with KlickFlow. We will review your current migration plan against this ITSM migration checklist ANZ framework, identify your highest-risk gaps, and give you a prioritised preparation plan. No obligation. Just a clear picture of where you stand.
You can also read our article on why most ITSM migrations fail before go-live to understand the root causes behind the gaps this checklist is designed to prevent.
Sources
- Salesforce. (2025). ITSM Migration: Why Customers Are Moving On From Legacy Tools. https://www.salesforce.com/service/it-service-management/itsm-migration/
- InvGate. (2025). ITSM Migration: A Complete 6-Step Guide. https://blog.invgate.com/itsm-migration
- Freshworks. (2024). Complete Guide to ITSM Implementation. https://www.freshworks.com/itsm/implementation/
- Kaopiz Software. (2025). The Hidden Complexity of Data Migration. https://medium.com/@kaopizsoftware