ERP Cutover Planning - The 72 Hours That Define Your Migration

We're planning our D365 F&O cutover for Q1 2025. After two years of preparation, configuration, testing, and training, everything comes down to one long weekend. The cutover period - typically 48-72 hours - is when you shut down the old system, migrate final data, validate, and bring the new system live.

This post is about how we're approaching cutover planning. Not the generic project management view, but the detailed operational reality of moving a food distribution company from a legacy ERP to a modern platform without losing orders, inventory, or customer trust.

Why Cutover Is Different

Everything before cutover is reversible. Discovered a configuration issue in testing? Fix it and test again. Found bad data? Clean it up. Users struggling with training? Retrain them. Timeline slipping? Adjust the date.

Cutover is irreversible. Once you're live on the new system, you're live. You can't easily go back - the old system's data is stale the moment you start entering transactions in the new one. The business keeps running, orders keep coming, and every minute of downtime costs money.

That irreversibility requires a different mindset. Every step must be planned, tested, and have a contingency. The goal isn't perfection - it's controlled execution with rapid response to problems.

Our Cutover Approach

Mock Cutovers

We've scheduled three mock cutovers before the real thing. Each one simulates the entire cutover process using production-equivalent data.

Mock Cutover 1 (completed): Focused on the technical process. Can we extract data from S2K, transform it, and load it into D365? How long does each step take? What breaks?

Results: The full data migration took 14 hours, longer than expected. Several transformation scripts had bugs. We identified 47 data quality issues that would have caused validation failures.

Mock Cutover 2 (scheduled): Focused on timing and orchestration. Run the full weekend simulation with the actual team. Test communication protocols. Validate that the timeline is realistic.

Mock Cutover 3 (scheduled): Dress rehearsal. Everything as close to real as possible, including business users validating their areas during the cutover window.

Each mock cutover generates a detailed lessons-learned document. We fix everything we find before the next one. By the real cutover, there should be no surprises.

The Runbook

Our cutover runbook is a 47-page document that specifies every task, who does it, how long it should take, what indicates success, and what to do if it fails. It's organized by time blocks:

Every task in the runbook has:

• A unique ID for reference
• An owner (single person accountable)
• Prerequisites (what must be complete first)
• Expected duration
• Success criteria
• Contingency if it fails or runs long

The War Room

During cutover, we'll have a physical and virtual war room. Key personnel are physically present; others join via Teams. The war room has:

• Large displays showing runbook status, system health, and open issues
• Direct communication channels to each functional team
• Printed runbooks and contact lists (if systems fail, we need paper)
• Food and caffeine (people work better when fed)

Communication is structured. Status updates happen every 30 minutes on a fixed schedule. Issues are logged in a central tracker with priority and owner. Decisions are documented in real-time.

We're deliberately not allowing side conversations or ad-hoc troubleshooting. When something breaks, it goes through the issue tracker and gets assigned. This prevents chaos and ensures nothing falls through the cracks.

Go/No-Go Decision Framework

We have three formal go/no-go checkpoints during cutover. Each one has explicit criteria.

Checkpoint 1 (Saturday 2 PM): Data Quality Gate

• All data migration scripts completed successfully
• Customer master record count matches within 0.1%
• Inventory counts match within 0.5%
• Open orders migrated and validated
• Pricing data loaded and spot-checked

If any criterion fails, we investigate. If it's fixable within the buffer time, we fix and proceed. If not, we escalate to the decision team (CEO, CFO, CIO) for a go/no-go call.

Checkpoint 2 (Sunday 3 PM): Business Readiness Gate

• All integrations tested and functional (BFC Dakota, Adobe Commerce, Shopify, Paycom)
• Sample transactions processed end-to-end
• Key users have validated their areas
• Support team briefed and ready
• Rollback plan still viable (we haven't passed the point of no return)

This is the last checkpoint where rollback is relatively clean. After this, we're committed.

Checkpoint 3 (Monday 6 AM): Production Gate

• First morning transactions processed successfully
• No critical issues open
• All planned staff are present and operational

At this point, rollback would be extremely disruptive. This checkpoint is less about go/no-go and more about ensuring we have adequate support for the first day.

The Rollback Plan

Hope for the best, plan for the worst. Our rollback plan defines exactly what we do if cutover fails:

Before Sunday 3 PM: We can restore S2K from backup, discard D365 data, and resume operations on the old system. Estimated recovery time: 4 hours. Data loss: transactions entered in D365 during the cutover window (should be minimal).

After Sunday 3 PM: Rollback becomes painful. We'd need to export any transactions entered in D365 and manually re-enter them in S2K. Estimated recovery time: 8-24 hours depending on transaction volume. We'd also need to explain to customers why their orders are delayed.

After Monday operations begin: Rollback is essentially not viable. We'd have parallel systems with inconsistent data. The recovery effort would be weeks, not hours. At this point, we fix forward - throw resources at problems and keep D365 running.

This escalating commitment is why the go/no-go checkpoints matter. We're consciously choosing to reduce our options as we proceed, and we need to make that choice with clear eyes.

Risk Mitigation Strategies

We've identified specific risks and built mitigation into our plan:

Risk: Data migration takes longer than expected
Mitigation: Built 6 hours of buffer into the timeline. Mock cutovers validate actual timings. Can run multiple migration streams in parallel if needed.

Risk: Integration failures with BFC Dakota
Mitigation: BFC team on standby during cutover. Pre-tested integration with production-like data. Manual fallback procedures documented (we can process orders manually for 24 hours if integration fails).

Risk: Performance issues under load
Mitigation: Load tested with 2x expected transaction volume. Azure capacity pre-provisioned. Monitoring in place to detect degradation early.

Risk: Key personnel unavailable
Mitigation: Every role has a designated backup. Critical roles have two backups. Nobody is single-threaded on any task.

Risk: S2K backup failure
Mitigation: Multiple backup methods (native backup, Veeam, manual export). Backup validation before any cutover activities begin.

Risk: User errors on first day
Mitigation: Floor support - IT and super users physically present in warehouse and office. Hotline for immediate assistance. First few days run with double-checking on critical transactions.

Communication Plan

Cutover affects everyone: employees, customers, vendors. We've planned communications for each group.

Employees: Full briefing two weeks before cutover. Daily updates during cutover week. Clear instructions on what to do Monday morning. Direct support channel for questions.

Customers: Advance notice that our systems will be transitioning. Request to place orders before Friday if possible. Explanation that order confirmations might be delayed over the weekend. Customer service team briefed on what to say if customers call during cutover.

Vendors: Notice that EDI might have temporary disruption. Request to not change anything on their side during the cutover window. Contact information for our team if they see issues.

We're deliberately over-communicating. It's better for people to feel informed than to be surprised by problems.

Post-Cutover Support

Go-live isn't the end - it's the beginning of a new phase. Our post-cutover plan includes:

Week 1 (Hypercare): All hands on deck. Extended support hours. Daily standup meetings to address issues. Quick-fix deployments if critical bugs emerge.

Weeks 2-4: Reduced but still elevated support. Focus shifts from firefighting to stabilization. Begin addressing non-critical issues.

Month 2+: Transition to normal operations. Support returns to standard levels. Begin optimization and Phase 2 enhancements.

We've pre-negotiated with our implementation partner for dedicated support resources during hypercare. This isn't the time to rely on normal support ticket queues.

Personal Readiness

Big cutovers are exhausting. 72 hours of high-stakes work takes a toll. Personal preparation matters:

• Sleep well the week before. You can't bank sleep, but you can avoid starting depleted.
• Arrange family coverage. Someone else handles the kids, the errands, everything non-essential.
• Pre-position food and supplies. You won't have time to go buy things.
• Clear the following week. Don't schedule other commitments when you'll be recovering.

I've done cutovers before, including the 2016 NAV go-live disaster at the company where I rebuilt SQL servers for 72 hours straight. That experience taught me that the technical work is only part of it - you also have to manage yourself and your team's endurance.

What I'm Still Nervous About

Despite all the planning, some things keep me up at night:

The unknown unknowns. We've tested extensively, but production has a way of surprising you. Some interaction we didn't anticipate, some data condition we didn't encounter in testing, some timing issue that only appears under real load.

Human factors. People make mistakes under pressure. Someone clicks the wrong button, runs the wrong script, or misses a step. We've built validation into the runbook, but we can't catch everything.

Integration timing. Our integrations with BFC Dakota, Adobe Commerce, and Shopify all need to switch over in a coordinated way. Timing is tricky, and a mismatch could cause data inconsistency.

These nerves are appropriate. They keep us sharp and drive additional preparation. The goal isn't to eliminate anxiety - it's to channel it into productive planning.

Final Thoughts

ERP cutover is a team sport. No individual - not the CIO, not the implementation partner, not any super user - can make it succeed alone. Success comes from months of preparation, clear processes, explicit communication, and the discipline to follow the plan even when things get stressful.

We're three months from our cutover date. The runbook is drafted. Mock cutovers are scheduled. The team is training. When January arrives, we'll be as ready as we can be.

I'll write more after the actual cutover - what worked, what didn't, and what we learned. Until then, wish us luck.