An ERP data migration estimate should account for more than the transfer. Before approving the workload, project leaders need to know what the business intends to keep, which rules remain unsettled, and who will make time to validate the result.
Start with a useful distinction: extracting existing data is a technical task; deciding what belongs in the future operation is a business responsibility. Plan for both. Otherwise, the estimate leaves its most important assumptions outside the discussion.
The planning guidance below applies a scoping and governance perspective to migration. The aim is not to settle every question before work begins, but to distinguish what can proceed from what still requires investigation or a decision.
Define the business boundary before the extraction list
Do not let the contents of the legacy system become the migration strategy by default. Separate the information available today from the information needed to operate in the new ERP.
For each significant data category, ask business and IT owners to establish a proposed boundary:
- Operational need: identify the records required to transact, serve customers, manage suppliers, or run operations.
- Historical access: distinguish information that should enter the ERP from information that might remain available through another approved arrangement.
- Business meaning: flag definitions, statuses, and classifications that need agreement before mapping.
- Acceptance: name who will assess whether the migrated data is fit for its intended use.
Start with categories that raise consequential scope questions, rather than trying to resolve every field. Record exclusions as explicitly as inclusions, and refer retention and access requirements to the appropriate internal owners.
The output should be a scope proposal that people can approve or challenge. An inventory describes what exists; it should not stand in for a decision about what to migrate.
Turn data issues into decisions with owners
OLING’s ERP practice identifies unclear governance and poorly synchronized functional and organizational decisions as recurring project concerns. It also flags dispersed responsibility for resolving functional disagreements. In migration planning, address these concerns at the level of individual decisions.
“Customer data needs cleaning” is a description of work, not an instruction that a team can reliably execute. Make the decision explicit: what constitutes a duplicate, who approves the matching rule, and who may authorize an exception?
Separate responsibilities without automatically creating another committee. Business owners should define meaning and acceptable use. Technical teams should assess implementation and checks. Project coordination should connect the decision to dependencies, capacity, and sequencing. An identified decision-maker should resolve disagreements that the working group cannot settle.
Check availability as well as authority. Naming a business owner is not the same as securing their participation in rule definition, exception handling, and validation.
Build the estimate around work and uncertainty
Before presenting a total, break the migration effort into activities whose assumptions can be examined. As a planning checklist, consider:
- Inspecting representative source data and documenting open questions.
- Agreeing on scope, definitions, mapping rules, and exceptions.
- Preparing or correcting data under approved rules.
- Configuring or building transfer and checking mechanisms.
- Running trial migrations and investigating discrepancies.
- Obtaining business validation and preparing the final transition.
For each activity, distinguish technical effort from business participation. Ask business managers to review the contribution expected of their teams alongside their other responsibilities. Do not treat that capacity as implicitly available.
Keep three things separate in the estimate: agreed work, work based on assumptions, and work that still needs investigation. Where a rule is unresolved, state the assumption used and what would trigger a revision. Where source data has not been examined, propose a bounded assessment before committing to a detailed workload.
Do not confuse effort with elapsed time. Show both the work required and the dependencies that determine when it can happen. A task awaiting a business decision should appear as such in the plan, not disappear inside a technical estimate.
This gives the approval discussion a firmer basis: what is included, what remains conditional, whose capacity is required, and when the estimate should be revisited.
Use workshops to close specific decisions
OLING’s ERP approach includes organizing working sessions and formalizing their outputs. Apply that discipline by giving each migration workshop a bounded decision to address—not simply a broad topic to discuss.
The treatment of inactive records, an unresolved classification, or acceptance criteria for one data category can provide a workable focus. Use representative examples where appropriate, without circulating unnecessary sensitive information.
Close the session with a record of the agreed rule, its scope, its owner, and any exceptions awaiting resolution. If participants cannot decide, identify the missing information and who should provide it. Do not label an unresolved discussion a validated requirement.
A simple decision map can support follow-up: list data categories against scope, ownership, rules, validation, and readiness. Leave unresolved items visibly open. Use those gaps to set the next working agenda rather than covering them with reassuring status labels.
Test migration choices against the future operating model
Underestimating organizational impacts is another explicit point of vigilance in OLING’s ERP consultants. Before accepting the migration plan, examine what its rules would mean for daily work after the transfer.
For example, before consolidating duplicate records, ask the affected teams to agree on future record ownership. Before replacing a legacy classification, establish how users should interpret and maintain the new one. These are questions to resolve, not reasons to assume that either technical treatment is appropriate.
Extend that review to ongoing responsibilities: who creates records, who maintains shared definitions, and who handles exceptions? Where a proposed cleansing rule implies a change in responsibilities or process, make that change explicit.
A migration tool should not substitute for an unsettled operating decision. Equally, planning should not stop until every organizational question is closed. Identify the decisions required for the next step and the questions that can be developed in parallel.
Make the roadmap a basis for commitment
OLING’s ERP consultants covers scoping, governance, and project structuring during initial planning, project restart, or delivery acceleration. Its approach is progressive: structure the scope, workshops, and roadmap before expanding the engagement.
Its usual ERP deliverables—a scoping note, workshop summaries, and a deployment roadmap—provide a useful sequence for connecting migration decisions to execution. In the scoping note, set out the proposed boundary, objectives, responsibilities, and material assumptions. In workshop summaries, separate decisions from open issues. In the roadmap, show the delivery sequence and the conditions for moving forward.
Before committing further capacity, bring project and business leaders together around three tests:
- Scope: is the boundary explicit enough to support the next estimate?
- Ownership: are decision authority and business participation agreed?
- Readiness: are unresolved assumptions and dependencies visible in the plan?
OLING identifies shared business and IT governance and promptly documented decisions as ERP success factors. Apply that principle to the next migration review: bring a scope proposal, a decision map, and an effort breakdown—not just a target date.
The decision is then concrete: authorize the work that is sufficiently defined, commission the investigation that is still needed, and escalate the choices that block further commitment.