Platform Migration Checklist: How to Switch Without Downtime
A successful platform migration requires four phases: discovery (2 weeks), parallel build (4–8 weeks), controlled cutover (1 week), and stabilisation (2 weeks). The key to zero-downtime migration is running both systems in parallel, with a rollback plan at every stage. Most migration failures come from skipping the parallel phase.
Platform migrations are the most underestimated projects in technology. A migration that 'should take 4 weeks' routinely takes 12. The reason: every migration surfaces hidden complexity. Data that looked clean has edge cases. Integrations you forgot about break. Team workflows change in ways nobody anticipated.
Phase 1: Discovery (2 weeks). Audit everything: data schemas, integrations, automations, user workflows, permissions, and edge cases. Document what the current system does, not what it was designed to do — these are often different. Map every integration, including the ones that 'just work' and nobody thinks about.
Phase 2: Parallel Build (4–8 weeks). Build the new system alongside the old one. Import data, configure integrations, and set up automations. Run both systems simultaneously. Compare outputs. When they match consistently, you're ready for cutover. This is the phase people skip. Don't skip it.
Phase 3: Controlled Cutover (1 week). Switch a small group of users first (canary release). Monitor for issues. Expand gradually. Keep the old system running in read-only mode. Have a documented rollback plan that can be executed in under 30 minutes.
Phase 4: Stabilisation (2 weeks). Monitor everything intensively. Fix issues as they surface. Gather user feedback. The first two weeks after cutover will reveal problems that testing didn't catch. Budget time for this explicitly.
The most dangerous words in a migration: 'We'll figure it out during cutover.' Every decision should be made before cutover weekend. Every script should be tested. Every rollback path should be documented and rehearsed.
If AI agents or MCP servers depend on the platform you are migrating, include them in discovery. Tool schemas, auth tokens, and webhooks break as often as classic integrations. Parallel-run the agents against both systems before cutover.
For Australian teams, Privacy Act and data residency constraints should be checked in discovery, not after cutover. Export paths, retention, and who can access staging data belong in the migration runbook.
Marshall Tech supports migrations as part of broader tech consultancy and stack work. Book a diagnostic if you need an external cutover plan.
Frequently Asked Questions
8–16 weeks for a standard business application (CRM, project management, ERP). Complex migrations with multiple integrations and large datasets can take 3–6 months. The discovery phase should give you a reliable estimate. Distrust any estimate made before discovery.
Yes, with proper planning. The parallel-run phase catches data mapping issues before cutover. Incremental sync (rather than big-bang data dumps) ensures data stays current in both systems. Always maintain a rollback capability for at least 30 days post-cutover.
Phased migration is almost always safer. Migrate one department, one data type, or one workflow at a time. This contains blast radius, builds team confidence, and lets you apply lessons from each phase to the next. Big-bang migrations are appropriate only when the systems are too tightly coupled to separate.
Sources
- Google Cloud: Migration Planning(accessed 2026-08-10)
Related resources
Move from this article into proof, definitions, and adjacent decision support.
Expert insight
On zero-downtime platform migrations
The most dangerous words in a migration: 'We'll figure it out during cutover.' Every decision should be made before cutover weekend. Every script tested. Every rollback path documented and rehearsed.
Updated 25 Jan 2026
Open resourceExpert
Nick Hugh
Nick Hugh, Principal AI Engineer & Fractional CTO at Marshall Tech, Sydney
Updated 10 Aug 2026
Open resourceExpert insight
On managing platform lock-in risk
Always build with the assumption that you might migrate away from any platform. Ensure you can export your data. Never put mission-critical business logic inside a platform you don't control.
Updated 5 Jan 2026
Open resourceCase study
KIKOFF: Backend Overhaul & Multitenancy Platform Build
KIKOFF needed a complete backend overhaul and a scalable multitenancy platform for managing sports leagues, venues, and teams across multiple organisations. Marshall Tech provided fractional CTO services, overhauling the backend architecture and building a multitenancy product that allows rapid feature development and seamless organisation onboarding.
Updated 26 Feb 2026
Open resourceInsight
5 Signs Your CRM Needs a Rescue
The five signs your CRM needs rescue: workflows failing silently, pipeline reporting you can't trust, lead response times exceeding 24 hours, team members maintaining shadow spreadsheets, and three or more failed attempts to fix the same issues. If any two apply, a 3-week rescue sprint will save months of accumulated damage.
Updated 10 Aug 2026
Open resourceCase study
UNDR CTRL: Simplifying the Platform & Bringing It In-House
UNDR CTRL needed a partner to help simplify their existing platform, build out some new features, and move away from their previous development provider. Marshall Tech worked closely with the team over several months to tidy up the codebase, ship new functionality, and hand over a cleaner, more manageable product.
Updated 21 Mar 2026
Open resourceLast updated: