Running Old and New Systems During an ERP Rollout. Decide which system owns each record while both are in use.
A phased ERP rollout needs a deliberate operating model for the period when old and new systems coexist. Define where each business event starts, which record is authoritative, how information crosses the boundary, and who resolves exceptions. Give every temporary arrangement an owner and a retirement condition.
The transition may last longer or behave differently than the original plan assumes. Treating it as a complete operating state makes those changes easier to evaluate. The business still has to fulfill orders, control inventory, close its books, and answer customers while the next wave is being prepared.
Start by drawing what will be true immediately after the first wave. The target architecture alone cannot tell a user which system to open tomorrow morning.
Describe each wave as an operating state
A rollout plan usually names dates and locations. Add a state description for each interval between those dates.
For every state, identify the sites and functions using each system, the transactions that remain open, the data that must be shared, the reports people will use, and the teams providing support. Include any external services whose behavior changes.
Then trace a small set of end-to-end business events across that state. Useful candidates include a customer order fulfilled from more than one location, an inventory transfer between sites, a purchase receipt followed by an invoice, and a return against an earlier sale.
Focus on boundary crossings. A process can work within each system while the handoff between them remains ambiguous. The transition design needs to show what happens when the originating record and the completing event live in different places.
Assign authority at the right level
“The new system is the source of truth” is too broad during coexistence. Authority may differ by data element, organizational scope, and transaction state.
For example, one process may authorize customer-address changes in the new system while the old system continues to hold the authoritative history for orders that originated there. A replicated address is a downstream copy. An open order is a business transaction with its own ownership and completion rules.
Create an authority register with these fields:
- Data element or transaction type: ______
- Entity, site, or population covered: ______
- State or effective period: ______
- Authoritative system and business owner: ______
- Allowed creator and updater: ______
- Downstream copies and permitted uses: ______
- Conflict rule and exception owner: ______
- Change that transfers authority, including effective time: ______
Assign a single authority for the defined item and state. If multiple teams may propose updates, define how those proposals reach the authorized owner. Do not rely on users to remember which copy was edited most recently.
Make authority visible in procedures and permissions where practical. If a legacy field must no longer be updated, communicate the rule and evaluate a technical restriction. A label in a project document provides little protection when the old screen still appears usable.
Follow one transaction across the boundary
Consider a hypothetical company rolling out by warehouse. Warehouse North has moved to the new system. Warehouse South still uses the old one. Inventory transfers continue between them.
A transfer request begins in the system designated for the sending warehouse. The receiving warehouse needs a corresponding expected receipt. Both sides need a shared transfer identifier and a way to distinguish the business transfer from individual messages about it.
Now examine the difficult cases. What if only part of the stock arrives? What if the receipt message is delayed? What if the same message is sent twice? What if the shipment is canceled after the receiving record has already been created? What if the next rollout wave changes where an outstanding transfer should be completed?
Write the expected transaction states and authorized actions before deciding how to build the bridge. The design should distinguish dispatched, in transit, partially received, completed, canceled, and disputed states where those distinctions matter to the business.
The specific accounting and inventory treatment must follow the organization’s approved policies. The transition team’s task is to make the event, ownership, and evidence explicit enough for the responsible owners to validate that treatment.
Give every bridge a control loop
A temporary bridge may be an interface, a scheduled file, or a controlled manual process. Its implementation can vary; its operating responsibilities still need definition.
Originate. Identify the authorized source event, its reference, effective time, and required data. Record the intended recipient and business effect.
Transfer. Define how the information moves, how transmission is logged, and how incomplete or invalid data is handled.
Acknowledge. Distinguish arrival from successful business processing. A file reaching a folder does not by itself show that the receiving transaction was accepted.
Reconcile. Compare the relevant populations and outcomes using shared identifiers and agreed cutoff rules. Identify missing, duplicate, rejected, or differently valued records.
Resolve. Route each exception to an owner with an approved correction or recovery procedure. Preserve the relationship between the original event and any correction.
Retire. Remove the bridge only when the successor process and remaining obligations have been verified.
For the warehouse example, a transfer can be transmitted successfully while its receipt fails validation. The monitoring view should expose that distinction. Otherwise, a technical success message can be mistaken for a completed business event.
Design the exception queue as real work
A queue needs more than a place to store errors. Define how an item is identified, who owns it, how urgency is determined, what information is needed to resolve it, and when unresolved work escalates.
At minimum, capture the business reference, source event time, current state, affected operation, reason for the exception, assigned owner, next action, and resolution evidence. Make the age of unresolved items visible relative to the business obligation they may affect.
Agree what users may do while an exception remains open. Can the warehouse receive goods? Can finance post the related invoice? Can customer service promise availability? Different cases may need different restrictions.
Rehearse absence and peak conditions. The person who understands a temporary bridge may also be a key participant in the next rollout. Name a trained backup and reserve operating capacity rather than assuming the project team will absorb every incident.
Make reporting boundaries explicit
Interim reports may combine records from two systems. Define the reporting population, business date, extraction time, transformation rules, and completeness checks before people use a combined total for decisions.
The same transaction may appear in both systems for legitimate reasons. Decide which representation contributes to each measure. For inventory transfers, the reporting design must address in-transit quantities and avoid treating mirrored records as additional stock.
Keep cutoff differences visible. A source report run after a late receipt and a destination report run before it are not necessarily inconsistent; they may describe different moments. Reconciliation should establish the relevant as-of basis and distinguish timing differences from errors.
For period end, finance should approve the interim close procedure, required reconciliations, exception treatment, and review responsibilities. Test that procedure during rehearsal, including outstanding cross-system transactions. Do not assume that the final-state close process can simply be split between two systems.
Budget the temporary operating burden
A bridge can be cheaper to build and expensive to run, or more expensive to build and easier to control. Compare the total expected burden over the credible coexistence period, including a scenario in which a later wave slips.
Include support coverage, reconciliation effort, training, access administration, duplicate reference-data maintenance where unavoidable, infrastructure, licenses, and retirement work. Separate one-time build effort from recurring operating effort so a schedule change has a visible consequence.
A manual bridge may be reasonable for a limited, observable transaction population with adequate controls. It becomes less attractive when volume, complexity, staffing, or duration exceeds the agreed boundary. An automated interface still needs monitoring, recovery, and ownership.
Record the assumption that would cause the chosen approach to be reconsidered. That could be another site joining, an exception queue exceeding manageable capacity, or a rollout delay extending the temporary state. The organization should set these triggers using its actual obligations and evidence.
Train for the interim state people will use
Users need instructions that match their location, role, and wave. A target-state training course may leave them unsure where to create an order, check stock, or correct a rejected transaction during coexistence.
Prepare a short role guide answering four questions: where do I start the work, which record do I trust, how do I know the handoff succeeded, and who helps when it fails? Include the relevant exception routes and forbidden duplicate-entry behavior.
Retire outdated guidance visibly when a wave changes. If a user keeps both instructions, clearly identify the effective dates and populations. Help-desk routing should make the current operating state apparent so incidents reach someone who understands the boundary.
Define exit evidence before the bridge opens
Give each temporary arrangement its own retirement record:
- Business flows it supports and remaining open transactions: ______
- Successor process and responsible operating owner: ______
- Reconciliation required before transfer or closure: ______
- Treatment of outstanding exceptions and late-arriving events: ______
- Required access changes and procedure updates: ______
- Historical information and retention needs: ______
- Verification evidence and authorized retirement decision: ______
A scheduled wave date is not sufficient evidence for shutdown. Confirm that relevant open items are completed or deliberately transferred, that late events have a route, and that the successor process works under the agreed conditions.
If a wave is postponed, revisit authority, support capacity, cost, and risk before simply extending the calendar. If a wave fails, use the approved contingency design; switching users back does not automatically reverse transactions already created in the new state.
The practical next step is to select one cross-system business event and trace it from initiation to reconciliation. Once the team can explain who owns every state and how the temporary bridge ends, it has the foundation for an interim operating model the business can actually run.
