Cutover

A company has tested a new order system, but customers are still using the old one, and the final switch is not just a software release. Orders, inventory, user access, integrations and staff instructions all have to move safely, and that coordinated transition is cutover.

Microsoft's Dynamics 365 guidance describes cutover as the last step before the new solution launches, with a strategy, detailed tasks, rehearsal, production execution and sign-off, and its Power Platform guidance discusses planning the final data migration, which shows that the work is operational, not merely technical. Define the exact moment the new system becomes the source of truth, because without it staff may enter the same transaction twice, and list every dependent system, such as payments, shipping, finance and reporting, since a successful login screen does not prove end-to-end operation.

Choose a window that fits the business, because a quiet period can reduce risk but holidays and staffing availability matter too. Name an owner for each step and a person who can make the go/no-go decision.

Freeze or restrict changes where necessary so the team knows which old-system records can still move after the final copy, and take a backup under the applicable retention and recovery rules, confirming that it can actually be restored. Reconcile key counts and totals between old and new systems, such as open orders, balances, products and user permissions, noting that a data migration may run in stages and the final delta captures records created since an earlier test or initial transfer.

After switching, test a realistic transaction in production, such as an order through fulfilment and accounting, and check user roles, because a system can function technically while giving the wrong people access to sensitive records. Prepare customer and staff communication that says what may be unavailable and where to report problems, and rehearse the steps in an environment that resembles production, since a rehearsal can expose missing tasks and overly optimistic timings.

Measure task duration so the cutover window includes contingency, because a data import can take longer at real scale, and set acceptance criteria before the switch, for example that all critical orders reconcile and payments complete without unexplained errors. Choose a decision time for rollback or another fallback, since a vague promise to decide later may leave too little time to restore service.

Rollback is not always simple, because new transactions may have been created after go-live and those records must not be lost. If rollback is impractical, define a safe manual process and a way to reconcile work once the new system is repaired, and log deviations during the cutover, since a changed sequence can create a hidden dependency later.

Watch the first operating period after go-live, because error rates, customer contacts and data mismatches may emerge only under real use, and make sure support staff have current runbooks and escalation contacts, since the implementation team may not be available indefinitely. A successful cutover ends with handover to business owners, not merely a green deployment dashboard, and for a small change the plan may be short but still needs explicit ownership and a tested path to recover from failure.

Avoid scheduling a cutover just before a financial close or critical reporting deadline unless the risk has been accepted, and document which records remain in the old system for reference and who may access them. Check any legal or contractual retention duties before disabling the previous platform, because the goal is continuity: customers and staff should know which system to use, while the business can trace every important transaction.