Quoting ERP data migration: what must be available at launch?

When a business wants to replace its ERP, “we will take the data with us” initially sounds like one task. Your proposal actually involves several decisions. What information do employees need when work begins in the new system? Which open transactions should continue there? Which older information should remain available through a separately agreed arrangement? A deliberate migration boundary helps the customer prepare the change and understand the services offered. It also prevents a general replacement wish from silently becoming a commission to recreate the entire past.

This article is for ERP providers and implementation partners defining migration scope before a proposal. Its questions and working documents are suggestions for your own consulting, not information automatically supplied with an enquiry. All examples are fictional. The text makes no legal statements about retention or deletion. The customer separately clarifies requirements for continued access with the appropriate specialists. Do not promise an import capability before your team has examined the actual source and target environments.

Derive data needs from the first working day

Ask the customer to describe the first complete task in the new ERP. A fictional retailer wants to continue an existing order and create a new one. Ask which products, business partners and outstanding quantities must be known. This produces an initial list of data categories, not a finished technical import list. For your proposal, first establish what work the customer wants to perform after the change and what information it genuinely requires.

Then examine a second workflow involving other people. Purchasing might need to follow an already confirmed procurement. Ask whether it should be entered again or migrated and which references must remain. Two concrete tasks raise different questions from a blanket request for all data. Record which processes are outside the initial launch too. The customer can assess a deliberately limited start while preserving future wishes.

Separate master data from unfinished work

Organise information by its purpose. Master data describes products and business partners, for example; open transactions represent work still to be completed. A customer record alone does not explain which order remains to be delivered. For every required category, ask which transaction should be possible in the new system. This gives your proposal a business structure the customer can assess without knowing the old application’s table structure.

Discuss links between categories. An open order may need appropriately mapped products and business partners in the target. Ask whether the customer can follow those mappings, not merely whether both lists exist. If an old number will be used differently, assign responsibility for that decision. A successfully loaded record alone does not prove that employees can complete the intended business task with it.

Give historical information its own decision path

Ask how older transactions will be used. Does sales want to look up previous orders, does management need comparison figures, or should employees find old documents? These wishes need not share one solution. Record each purpose before deciding what to migrate. The customer can distinguish launch data from separately clarified historical access. Do not promise full comparability of old reports or a particular archive arrangement without investigation.

State explicitly which historical content is outside the proposed migration. This does not authorise deletion. Clarify who investigates continued handling on the customer side and what decision is necessary before switching off the old system. Involve appropriate specialists when legal or tax questions matter. Your scope describes the migration service; it does not replace that assessment. A deliberate open item is more useful than silently assuming a complete history transfer.

Identify the actual source for each category

Ask the customer to identify the source of every required dataset. Products might be in the ERP, supplementary mappings in a spreadsheet and outstanding purchase orders in another application. Ask who maintains the source and which point in time it represents. A suitably named file is not yet a confirmed current dataset. Descriptions and invented examples suffice initially. Real exports belong in a separately agreed suitable review process with responsible participants.

If several sources contain the same information, your team needs a business decision about the authoritative version. Discuss which product description should apply when records conflict. Do not create rules yourself from apparently plausible file contents. The customer confirms the intended version; your team examines how to migrate it. Content ownership remains traceable, and implementation receives a clear basis instead of making hidden cleansing decisions during import.

Agree specific cleansing tasks

Discuss data problems through their effect on launch. Duplicate products, missing mappings and contradictory units need different decisions. Ask who reviews them from a business perspective and what cleansed state the migration team should receive. “The customer supplies clean data” is too vague. Name the category and expected result. If your company actually offers cleansing, define that service explicitly too, rather than silently combining it with the technical import.

Plan how to handle cases that cannot initially be decided. Should a disputed product be deferred, does the customer need an interim arrangement, or does the open issue block the launch task? Answer this through the work required at launch. Do not invent a generally acceptable error rate. Agree who decides each unresolved case and how its treatment is documented, allowing the customer to make a conscious scope decision.

Check a connected sample dataset

Ask the specialists to select a small, meaningful sample showing the required connections: for example a product, its business-partner relationship and an open order. You can invent the entire sample for initial consulting. Suitable data for later testing is agreed separately. The selection should also represent a real characteristic of the planned workflow, rather than only the simplest standard case everyone already expects.

Agree beforehand how the business team will assess the outcome. Can it identify the migrated order, understand the outstanding quantity and perform the next task? Who confirms this for which dataset? An import completion message does not answer those questions. Record technical processing separately from business usability. If something fails, investigate precisely whether the source, mapping or intended continued processing needs a different description.

Plan for changes between rehearsal and migration

Data can change between a trial and the planned switchover. Ask which employees continue working and which categories are affected. Will you later need a new complete dataset or a validated method for changes? The technical decision follows actual working practices and system capabilities. For the proposal, establish that trial data is not automatically the final state and that someone owns the last update.

Walk through a late change. In the fictional case, part of an order is delivered after the trial. Which outstanding quantity must appear in the new system, and who confirms it? Without a clear answer, migration of that transaction is insufficiently described. Record the question and its owner. It then enters focused migration clarification instead of becoming unexpected extra work during the actual switchover.

Assign customer contributions clearly

Agree someone for each category who can explain its contents and obtain business decisions. This need not be the person who technically creates an export. Ask who organises post-migration review and responds to discrepancies. The customer sees what participation the desired scope requires; your team can describe its own tasks accordingly. Assignment along actual datasets is more useful than a general promise to cooperate.

Summarise the scope in a readable list or short prose: category, source, launch purpose, intended data state, responsible people, review and explicit exclusions. Put outstanding technical prerequisites alongside it. If central information is missing, offer a bounded analysis first, provided it belongs to your genuine services. Describe its result without automatically promising later implementation. The customer can consciously choose further clarification or a sufficiently described migration commission.

Compare two genuinely different migration boundaries

The first fictional proposal migrates only the products and business partners confirmed for launch, plus selected open orders. Older completed transactions remain outside migration; continued access is a separate customer decision. The second proposal also makes older movements usable in the target. Compare both by intended use. More data alone does not make the second better; the customer’s confirmed benefit matters.

For every additional category, ask which work would otherwise be impossible. If the need is only occasional lookup, clarify the suitable access arrangement first. If an open transaction needs daily processing, its usability belongs directly in the launch decision. This enables concrete prioritisation. It replaces neither technical validation nor authorisation to remove information from the old system or terminate its operation.

Finally, ask the customer to summarise what should be available after migration and what intentionally remains open. If they mention a category missing from your description, resolve the difference before the proposal. Record the confirmed state and responsible people. A later addition can build on it without retrospectively portraying the original service boundary as broader than actually agreed.

Source context

Microsoft’s Dynamics 365 data-management guidance identifies master data and open transactions among migration data. This provides terminology here, not evidence of your solution’s capabilities or legal retention instructions.

Start new ERP project conversations

ERP leads from webRichtung open conversations with businesses in Germany seeking ERP proposals. Process area, current system situation, planning stage, location and contact details provide the starting point. You clarify migration scope yourself. Register your business and prepare your lead order in webRichtung Customer; you see the current price before making a binding order.