ERP import substitution: how to plan the transition

Management challenge

The main purpose of an ERP transition is to preserve business control: critical processes, data, reporting, integrations, roles and execution monitoring.

When the problem becomes visible

• Migration dates matter more than data quality
• Legacy logic is undocumented
• Only technical specialists know the integrations

How to design the solution

This approach keeps the discussion focused on management control rather than only on system functions.

• Audit the application landscape
• Separate critical and secondary functions
• Prepare the data model
• Run migration in controlled waves

Common mistakes

The most common mistakes appear when a team trades architecture quality for launch speed.

These mistakes may be hidden during a demonstration but become visible in production operation.

• Transfer every legacy customisation without review
• Skip parallel reconciliation
• Underestimate user preparation

Key takeaways

• An ERP transition starts with an audit.
• Not every legacy customisation should be retained.
• Data migration is a project in its own right.
• Business control matters more than formal replacement.

Answer for management practice

Migration should be planned as a transition of functions, data, integrations and accountability, not merely as a technical replacement. Each wave needs entry criteria, outcome reconciliation and a workable rollback path. For this task, the initial evidence is “different accounting rules across units”, and the decision boundary concerns balances, commitments and open transactions.

The practical focus is the integrity of the transactional core, master data, integrations and system transition. A decision is ready for approval when the object, owner, baseline, permitted action and outcome evidence are explicit; the reference object in this article is control reports and period close.

Applied analysis: ERP import substitution: how to plan the transition

The question “ERP import substitution: how to plan the transition” first requires agreement on the meaning of integration messages. Different definitions produce different data, requirements and outcome assessments even when one system is used.

Prepare a real example of the signal “different accounting rules across units” and locate its point of origin. Then assign the action “prepare data-cleansing and migration rules”, its owner and the permitted response time.

Review the risk “estimating cost from licences alone” before expanding scope. If the control fails in the first cycle, postpone scaling and refine the data, authority or decision boundary.

• Working object: Balances, commitments and open transactions.
• Diagnostic signal: Different accounting rules across units.
• Response action: Prepare data-cleansing and migration rules.
• Controlled risk: Estimating cost from licences alone.

Where the problem becomes visible

The work starts with an observable situation, not with interface selection. The diagnostic signal for this article is: different accounting rules across units. It should be supported by a real example such as a document, data sample, decision record or registered variance.

The first scope is limited to one object and one decision. Changing every process, master-data set and system at once obscures causality. For the signal “misaligned master data”, a representative boundary is a period, business unit or transaction class where the situation can be tested again.

• Diagnosis records “misaligned master data”, its recurrence and its impact on control reports and period close.
• Observation 2: Manual cross-system reconciliations. Required fields: frequency, source and consequence for financial and material documents.
• Signal: Unclear historical-data scope. Evidence includes an example, frequency and consequence for master data and identifiers.

Subject model and boundaries

The subject model starts with two reference objects: balances, commitments and open transactions and integration messages. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “authorise cutover against criteria”.

The primary boundary is balances, commitments and open transactions. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Control record 1. Object: Financial and material documents. Observable signal: Critical operations without a rollback scenario. Accountability: semantic owner and quality owner.
• Boundary 2. Object: Master data and identifiers. Define the source, frequency, permitted transformations and response to “misaligned master data”.
• Object 3: Balances, commitments and open transactions. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Manual cross-system reconciliations.

End-to-end scenario data

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is integration messages.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “different accounting rules across units”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Record 5. Object: Control reports and period close. Required details: identifier, lineage, quality rule and update event. Signal: Different accounting rules across units.
• Subject area 4: Integration messages. Verification basis: system of record, owner authority and the signal “unclear historical-data scope”.
• Object 3: Balances, commitments and open transactions. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Manual cross-system reconciliations.

Transition waves and rollback control

The method is a sequence of decisions rather than a universal checklist. For integration messages, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For balances, commitments and open transactions, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “prepare data-cleansing and migration rules”.

• Decision 1: baseline the current-system scope. The basis for the next step is control reports and period close.
• Step 2. Allocate functions to transition waves. Output: financial and material documents.
• Prepare data-cleansing and migration rules is the action at stage 3. The output documents master data and identifiers.
• At position 4, the action is “run parallel reconciliations”; its result is balances, commitments and open transactions.

Management question

The article addresses “ERP import substitution: how to plan the transition”. The adjacent management issue is how to plan the transition. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “misaligned master data”, the material risk is “estimating cost from licences alone”, and the testable action is “authorise cutover against criteria”. This chain turns a broad term into a concrete decision.

• Decision 1: object — financial and material documents; signal — unclear historical-data scope; action — prepare data-cleansing and migration rules.
• Decision 2: object — master data and identifiers; signal — different accounting rules across units; action — run parallel reconciliations.
• Decision 3: object — balances, commitments and open transactions; signal — critical operations without a rollback scenario; action — authorise cutover against criteria.

Evidence that the solution works

The acceptance criterion for control reports and period close includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “misaligned master data”, passes through an authorised decision and “authorise cutover against criteria”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1. Object: Financial and material documents. Test fields: baseline, target change, source and owner. Signal: Manual cross-system reconciliations.
• 2. Acceptance object: master data and identifiers; compare the baseline sample, expected change and confirmed actuals. Test signal: Unclear historical-data scope.
• Evidence item 3 describes balances, commitments and open transactions, comparable test conditions and the person accountable for interpretation. Signal: Different accounting rules across units.
• Test 4 concerns integration messages. The method, interpretation owner and outcome source are documented. Signal: Critical operations without a rollback scenario.

Controlling critical dependencies

The risk map starts with two conditions: “estimating cost from licences alone” and “migration without control totals”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

Every assumption has an owner, supporting evidence and a review event. The risk “migration without control totals” needs particular control here because its status affects the scope, delivery sequence and acceptance criterion.

• Risk review starts with the condition “copying legacy errors into the new system”. The decision uses the action “authorise cutover against criteria” and data about master data and identifiers.
• Risk record 2. Condition: Migration without control totals. Control action: Baseline the current-system scope. Evidence source: Balances, commitments and open transactions.
• Risk: Untested integration compatibility. Control: allocate functions to transition waves. Evidence: integration messages.
• Risk condition 4: Go-live with unresolved critical defects. Response: Prepare data-cleansing and migration rules. Testable evidence: Control reports and period close.

Decision-rights matrix

For control reports and period close, the role model determines more than screen access. In the action “prepare data-cleansing and migration rules”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For control reports and period close, this separation is especially important because of the risk “migration without control totals”.

• In the decision matrix, business owner connects control reports and period close with the action “baseline the current-system scope”.
• Architect: decision area — financial and material documents; control action — allocate functions to transition waves.
• Data owner is accountable for master data and identifiers and confirms the action “prepare data-cleansing and migration rules”.
• Role: Project manager. Decision object: balances, commitments and open transactions; verified step: run parallel reconciliations.

Materials for starting work

The first working session on balances, commitments and open transactions uses real material: a transaction example, report or plan, systems diagram, role list and the variance “different accounting rules across units”. Participants select one scenario, identify data gaps and perform the action “prepare data-cleansing and migration rules”.

The output is a decision pack: problem statement, object map, baseline sample, owners, dependencies, verification criteria and open questions. The risk “estimating cost from licences alone” helps determine the next format: a pilot, architecture discovery, competitive selection or process correction without a new system.

• Decision 1: baseline the current-system scope. The basis for the next step is control reports and period close.
• Step 2. Allocate functions to transition waves. Output: financial and material documents.
• Test 4 concerns integration messages. The method, interpretation owner and outcome source are documented. Signal: Critical operations without a rollback scenario.
• Control record 5: Control reports and period close; data version, calculation rule, expected change and actual outcome. Signal: Misaligned master data.