Cutover planning for your ERP needs a roll-back condition; not just a “go live” date.
The “go live” date lets everyone know when the new ERP takes over but it doesn't let anyone know what to do when the numbers don't add up and/or a key business workflow fails at cutover. This decision should happen sooner.
Most of the time cutover plans are listed one-way.
They include the last data pull, user lock-out, import, reconcile, integration switch and communication. Each activity includes a specific owner and specific time stamp.
And then something fails.
The trial balance doesn't agree. Payroll won't post. The opening AR doesn't reconcile. There's a bank feed delay.
At this point the plan is now a meeting. Everyone would like to avoid delaying “go live.” Therefore, the system often goes live simply because the date exists and the roll back rule does not.
A go-live date is not a readiness test
Although a date provides value by forcing project decisions and providing a target for teams; it is not capable of representing that the system is ready for use.
Readiness can only be represented with conditions that are either true or false. The general ledger reconciles with the source data. Sub-ledger account values tie to control accounts. All required users can complete all transactions which they own.
All these conditions must be developed prior to cutover. If you develop them during cutover; they will disappear.
A cutover plan without a stop condition has only one possible outcome (to go live).
This is not a readiness test. It is a schedule.
The rollback condition needs a number and an owner
“The roll-back condition will be based on major problems” is not a roll-back condition.
Major means many things. A better condition is measurable. The trial balance must reconcile. The opening balances of customers and vendors must equal the total amounts approved from the source systems. All critical integrations must complete a predefined test. No severity-one issue may remain open.
In addition to being measurable, each gate also requires one individual who can authorize the gate.
Prior to cutover, a committee can be very helpful. During cutover, it can be slow. Once the deadline arrives; someone needs authority to state the condition was not met and therefore the original system remains as the primary system.
Without this authority; every problem becomes negotiable. Negotiating with respect to whether to continue past problems when a team has invested months preparing for one date is extremely risky.
Rollback does not always mean restoring a database
When using technical language such as “rollback,” people tend to think of complex technical activities associated with rolling back their entire database. However, the best way to implement an ERP rollout plan is often operationally related.
The old system remains active. Users do not enter transactions into the new system. Integrations continue pointing to the legacy environment. Any transactions received during the freeze remain queued until further notice.
Reversing imported objects after users have entered their first invoice, receipt and journal entries into the new system is more complicated than stopping once all users have finished entering data.
Returning to a previous point of entry is generally easier than recovering after numerous postings have been completed in the new system.
Therefore, the plan should identify the last possible safe point to stop. After this point, the focus shifts from roll-back to recovery.
Understanding this difference matters.
Reconciliation belongs inside cutover, not after it
If the new ledger contains incorrect opening balances, the very first close will contain some unknown variance. If there's subsequent activity, finding out why that was the case just got a lot tougher.
When we do a cutover, we want to explicitly verify that all of our accounts agree before we start making entries.
So, “does my trial balance add up correctly?” isn't enough. We want to check that our accounts receivable (AR) account agrees with its control account. That we're posting against the correct AP account. That our cash balances match what our company expects them to be. And so on.
And migration counts aren't insignificant either.
Just because your data loaded correctly doesn't mean you've eliminated risk. A “successful load” means nothing if many of the records that were expected didn't show up. A “successful load” means nothing if you now have two systems of record.
Parallel running is not the same as rollback
Parallel running can seem like a safety net. But parallel running only provides value if the organization knows which system is accurate. In most organizations, until the cutover gates pass, the legacy system is the authoritative source of truth. Once those gates pass, the new ERP system is the authority. And once those gates pass, neither system should allow users to make live postings.
Users can create a new reconciliation problem every single day by making postings in both systems simultaneously. Two changing ledgers don't provide redundancy; they provide two completely separate sets of financials.
Historical documents, such as prior-year invoices, old attachments and reports for prior years, etc. may still exist within the legacy system. However, using both systems to track financial transactions is not beneficial.
Test the rollback before you need it
Because teams usually test the happy path during their cutover rehearsal, they believe this is how they will always use the system. A better rehearsal would include testing for failure. Stop the dry-run after the load. Assume that one of your connections is broken. Create a reconciliation difference. Ask the team to execute the rollback procedure.
Who opens the legacy process again? Who changes the connection points? Who informs employees? How do transactions that occurred while frozen get handled?
If these questions are answered verbally rather than through action items, then the rollback has not been thoroughly tested.
Additionally, testing your rollback allows you to identify activities that cannot be reversed. Examples include bank files being sent off-site, payroll submissions being processed, third-party integrations being executed, etc.
These dependency issues should be included in your sequencing.
Therefore, a rollout plan should be treated with similar importance to your rollout plan when it comes to thoroughness of testing.
Where this argument is weak
Not every implementation will have a clean rollback. There could be regulatory deadlines looming, acquisitions pending, system shutdowns occurring or contracts expiring. Similarly, some companies generate large numbers of transactions per day and attempting a secondary cutover would cause far less disruption than fixing the current system in place.
In each of those scenarios, decisions need to be made.
However, regardless of whether an organization decides to implement a clean rollback or not, the team needs to understand which type of failures would stop the cutover and which would proceed to a controlled recovery process.
“No rollback available” is a legitimate limitation.
“No decision will be made until something breaks” is not.
The cutover plan needs two endings
Most project plans conclude with go-live.
A quality cutover plan includes two potential conclusions:
- The gates pass and the new system is designated as authoritative, the integrations are switched and users begin entering live transactions into the new system.
- A predetermined condition fails before the irreversibility point and the legacy system continues to serve as authoritative, the responsible party for the failing gate is identified and a subsequent cutover schedule is developed to fix the issue.
Each ending should be documented prior to either needing to happen.
An established go-live date creates pressure/urgency. An established rollback condition provides controls/governance.
You'll need both.