ERP go-live cutover checklist

Cutover is the short window when the business stops working in the old system and starts working in the new one. Most of what goes wrong in that window was decided weeks earlier: which data moves, in what order and who signs off. We work through the checklist below with distributors. It is grouped by phase, and each item gives the reason it is on the list.

Adapt it to your project. Strike through items that do not apply, and do it on purpose rather than by forgetting them.

Four to six weeks before go-live

These items turn the plan into something the whole company has agreed to. The later a decision changes, the more rehearsal work it throws away.

• Freeze design decisions. Pricing rules, chart of accounts, item numbering and workflows stop changing so the final rehearsal tests what will go live.
• Freeze master data changes in the legacy system, or log them. Every new customer or item added after the last extract must be re-keyed or re-loaded.
• Pick the cutover date around the business calendar. A date just after a month-end close, and away from your busiest season, gives you a clean starting balance and room to recover.
• Write the cutover runbook. A step list with owner, start time, duration and a check for each step, so nobody improvises at 2 a.m.
• Run a full dress rehearsal from the runbook. Load a copy of production data into a test environment in the real order, time each step and reconcile it, because the first run always finds a missing dependency.
• Fix and re-rehearse until the reconciliation ties. If a rehearsal did not reconcile, run it again.
• Collect written sign-offs. Finance signs the opening balance method, operations signs the inventory plan, each process owner signs their test results. With sign-offs in hand, the go/no-go call becomes a check against a list.
• Finish role-based training on the rehearsal data. Users learn faster on their own customers and items than on demo data.
• Name super users by department. They answer the first question on the floor and filter what reaches the project team.
• Set up the support plan. A single place to log issues, severity definitions, a triage schedule and vendor or partner contacts with after-hours numbers.
• Decide the rollback plan and its deadline. Write down what reverting looks like and the latest point it is still possible. NIST SP 800-34 is a good public template for thinking through recovery steps and decision points.
• Tell customers and vendors what changes. New invoice layouts, remittance addresses, EDI or portal changes and a possible short delay in shipping on day 1.

Cutover weekend

Work the runbook in order. Each block below ends with a reconciliation, and the next block does not start until the current one ties or the difference is explained and signed off.

Stop the old system

• Set the last-transaction cutoff and announce it. Every order, receipt, shipment and payment before the cutoff lives in the legacy system, everything after lives in the new one.
• Close or finish in-flight work. Ship or unpick picked orders, post open receipts and apply cash received, so fewer half-finished transactions have to move.
• Lock legacy users out of posting. Leave read-only access for lookups, but stop new transactions so the extract does not go stale.
• Take and store final legacy backups and reports. Print or save the trial balance, AR and AP aging, open order and PO lists and inventory valuation as of cutoff. They are the targets you reconcile to.

Load and reconcile the opening position

• Load or confirm master data. Customers, vendors, items, price structures and locations should already be loaded and frozen. Load only the delta since the last rehearsal.
• Count or confirm inventory. Take a physical count, or rely on a recent count plus cycle count accuracy you trust, because the new system starts from whatever quantity you load. ABC analysis and cycle counting covers how to know if your records are good enough.
• Load on-hand quantities and costs by location. Reconcile units by item and location, and extended value to the legacy inventory valuation, because cost errors hide in totals that look right.
• Load open sales orders. Include backorders, special orders and future-dated releases, and reconcile count and open value to the legacy open order report.
• Load open purchase orders. Include partially received lines and confirmed dates, since replenishment and available-to-promise depend on them.
• Load open AR by invoice. Load each open item, so customers can pay and dispute specific invoices, then tie total and aging buckets.
• Load open AP by invoice. Load open vendor invoices and any receipts not yet invoiced, and tie to the legacy AP aging and accrual.
• Post GL opening balances. Post the trial balance as of cutoff, with inventory, AR and AP control accounts tied to their subledger loads.
• Reconcile subledgers to the GL. Inventory, AR and AP subledgers must equal their control accounts on day 1, or every future reconciliation starts with an unexplained difference.

Switch the surroundings

• Switch integrations. Point EDI, ecommerce, shipping, tax, payment and banking connections at the new system and send a test transaction through each, because partners will keep sending to the old one until told otherwise.
• Confirm printers, forms and email. Print a pick ticket, packing list, invoice, PO and statement on the real printers, and send a real email of each to an internal address.
• Activate users and security roles. Give production credentials to the people who need them and check a sample of roles, since over-broad access on day 1 is hard to take back.
• Disable test settings. Turn off test email redirects, sandbox payment gateways and test EDI identifiers carried over from rehearsals.
• Run smoke tests by process. Enter, pick, ship and invoice one order, receive one PO, apply one payment and pay one vendor, end to end.

Running old and new systems in parallel

A parallel run, where users key every transaction into both systems, sounds safe and usually is not. Staff are doing double work during the hardest week of the project, the two systems drift apart within days and nobody is sure which balance is right. We recommend a clean cutover with a rehearsed rollback plan instead. If a regulator, auditor or lender requires a parallel run, keep it short, limit it to the processes it is meant to prove and name one system as the book of record from day 1.

Go/no-go criteria

Agree the criteria and who decides before the weekend starts. The meeting then checks facts against a list instead of weighing opinions under pressure.

Criterion	Go when	Owner
Inventory	Units tie by item and location, and extended value ties to legacy valuation within the agreed tolerance	Operations and finance
Open orders and POs	Record counts and open values tie to legacy reports	Customer service and purchasing
AR and AP	Open item totals and aging buckets tie to legacy agings	Finance
GL	Trial balance ties and control accounts equal subledgers	Controller
Integrations	A test transaction completed through each critical connection	IT
Forms and printing	Customer-facing documents print and email correctly	IT and customer service
Smoke tests	Every critical process completed end to end with no severity 1 issue open	Process owners
People	Super users on site or on call, support desk staffed	Project manager
Rollback	Rollback path still available and its deadline not passed	Project sponsor

If a criterion fails, the options are fix now, go with a documented workaround or roll back. Decide before the weekend which failures allow a workaround.

Day 1 to day 30: hypercare

Hypercare is the period of extra support after go-live. Most issues surface in the first two weeks, and the first month-end close is where the rest appear.

Every day

• Hold a short daily triage meeting. Review new issues, assign owners and confirm yesterday's fixes, so problems do not pile up unseen.
• Reconcile inventory, AR and AP subledgers to the GL daily. A difference found the next morning has only one day of transactions to search.
• Check integration queues and error logs. Failed EDI documents and web orders raise no alarm and turn into missed shipments.
• Watch order-to-ship flow. Compare orders entered, picked, shipped and invoiced each day with a normal day in the old system.
• Review negative on-hand and unusual cost changes. They point to receiving, unit of measure or costing setup problems while they are still few.

Every week

• Review open issues by severity and age. Old severity 2 issues become permanent workarounds if nobody owns them.
• Collect user feedback from super users. They hear the small frictions that never reach the issue log.
• Recheck security roles. Remove temporary access granted to get through the first days.

The first month-end close

• Run the first close as a rehearsed event. Walk through the close steps in advance, with extra time and the project team on hand. Month-end close for distributors is the checklist.
• Compare the first month's results with prior months. Margin, inventory value and aging that move sharply usually trace to a setup or load issue, not to the business.
• Hold a lessons-learned review and agree the exit from hypercare. End hypercare when the issue rate is back to normal and the close has tied, not on a fixed date.

Next steps

Copy this list into your project tracker four to six weeks out and assign an owner to every line. The rehearsal decides the rest, so schedule it early enough to run it twice.