How to Run an IT Migration Without Breaking Operations

Most IT migrations get framed as software projects. They aren’t. They’re operational change projects where the software change is one component. Companies that miss this distinction consistently break their operations during the transition.

Here’s how to migrate (any system — accounting, ERP, e-commerce, CRM) without breaking the business.

The mental model that works

Treat the migration as four parallel work streams, not one technical project:

1. The technical migration itself. Data export, transformation, import, testing.
2. The operational change. New workflows, new screens, new processes.
3. The training and adoption. People learning the new system without losing productivity.
4. The cutover plan. When and how the old system gets turned off.

Most failed migrations got the technical piece right and missed two or three of the others. The technical piece is the easiest part.

The four-phase migration pattern

Phase 1 — Parallel data, no operational change (4–8 weeks)

The new system gets stood up alongside the old one. Data flows into both. Nothing operational changes — your team keeps working in the old system. You’re using this phase to:

• Verify data is being captured correctly in the new system
• Surface integration gaps before they matter
• Let technical staff shake down the new system without operational pressure

This phase is where most “we found a problem” issues surface. Better here than after cutover.

Phase 2 — Pilot users (2–4 weeks)

A small group (3–8 people, ideally including one skeptic) starts using the new system for real work. The old system is still authoritative; pilots use the new one in addition.

What you learn:

• Whether the workflows actually fit the way the team works
• Where training material is unclear
• Performance and reliability under real use

Adjust based on what you find. Don’t proceed until pilots are comfortable.

Phase 3 — Wider rollout (2–6 weeks)

Expand to the full team. Old system still authoritative; everyone uses the new one alongside. This phase is mostly about training, support, and absorbing feedback.

The temptation here is to skip ahead and just turn off the old system. Don’t. The cost of a bad cutover is much bigger than the cost of running both for a few extra weeks.

Phase 4 — Cutover (1–2 weeks)

Old system becomes read-only. New system becomes authoritative. There’s a final data sync, then the switch.

What needs to be ready before cutover:

• Verified data parity between old and new
• Documented rollback procedure (how to switch back if something breaks)
• Support team standing by for 5 business days
• All integrations to other systems updated to point at the new one

Plan cutover for a low-volume time. End of week, start of a new month, slow seasonal period. Never during a known busy period.

What kills migrations

Five patterns we see consistently:

Skipping the parallel phase

“We don’t have time for parallel running.” This is the most expensive sentence in IT migration. The parallel phase is when you find the problems that would otherwise become emergencies after cutover.

Migrating bad data

The old system has years of accumulated data quality issues. Migrating them as-is means the new system inherits all the same problems. Plan for data cleanup as part of migration, not after.

Underestimating training

People learn new software faster than you think — but only if training is good. Plan formal training sessions plus a 2-week period where the support team is actively helping people. Skipping this means productivity drops after cutover and stays low for months.

Custom integrations forgotten until the last minute

The old system probably has 5–15 small custom integrations you forgot exist. Reports that pull data, automation that pushes notifications, scripts someone wrote three years ago. Audit these early; many need to be rebuilt against the new system.

No rollback plan

What happens if the migration fails 48 hours after cutover? Without a rollback plan, you panic. With one, you decide calmly. Always have an exit.

What this kind of project costs

For a typical SME migration (e.g., switching ERP or accounting):

• Discovery and planning: Rp 20–50 juta, 2–3 weeks.
• Technical migration: Rp 40–150 juta, depending on complexity.
• Training and change management: Rp 15–40 juta, often skipped (don’t).
• Parallel run period and support: Rp 20–40 juta in extra time.
• Total: Rp 95–280 juta typically.

The technical piece is sometimes 30–40% of the total cost. The other 60–70% is operational change management. Quotes that don’t include these are misleading.

Three things to insist on

If you’re hiring someone to run a migration:

1. A written migration plan with all four work streams. Not just technical. If they can’t articulate operational, training, and cutover plans, they don’t know what they’re doing.
2. Parallel running for at least 4 weeks. Non-negotiable. Vendors who push for shorter are saving themselves time at your expense.
3. A rollback plan in writing. What happens if things go wrong post-cutover.

If you’re approaching a major IT migration and want to scope it properly before committing, an hour of conversation usually clarifies the right shape. We do those at no cost.