ERP Selection and Migration: A Practical Guide

The ERP decision starts before the software demo

Choosing an ERP can change daily work across the company. Sales relies on customer and pricing data; purchasing on demand and stock; manufacturing on bills of materials, work orders and capacity; finance on traceable transactions; and service on schedules, parts and invoicing. An ERP connects these flows, so a decision for one department can affect the rest of the business.

That is why the ERP selection process should not begin with a list of features or a vendor’s standard presentation. It should begin with the company’s goals, its current processes, and the way it wants to operate in the future. If you are replacing an older ERP, the work is broader still. You must decide which processes and data should move, which should change, which systems should connect, and which old practices should be retired.

The central principle is simple: understand the scope before you choose the system or rely on an implementation price. This matters most when many business flows or individual development are involved. A short sales meeting may produce a preliminary budget range, but it cannot reveal every process, data, integration, migration, testing and training need.

ERP practitioners writing on LinkedIn describe the same pattern from different angles: demo-led selection, unclear requirements, unexamined legacy customizations, unprepared data and weak implementation planning can leave the hard decisions until after a contract is signed. These are practitioner observations, not statistical proof of project failure. They are still useful signals for the questions a buyer should ask early. [1][2][3][4]

First decide what kind of change the business needs

A company should not assume that a replacement ERP is the only answer. A system may need an upgrade, a reimplementation, selective replacement of connected tools, or a wider ERP change. The right path depends on the business problem, the technical condition of the current environment and the future operating model.

Do not replace a system only because it is old or because a new product looks more modern. Assess whether the current ERP can still support the required security, reporting, integrations, scale and business processes. LinkedIn migration adviser Sam Gupta makes this distinction directly: age alone does not make an ERP obsolete; the company should examine supportability, customization, integration limits, scale and future needs before deciding whether to stay, upgrade, reimplement or replace. [3]

The decision should also include what will not be changed. If the company has a process that works well and creates real customer or operational value, it may be worth preserving. If the same process exists only because the old system could not support a better method, copying it into a new ERP can carry the old problem forward.

Map the real business before comparing software

An ERP project needs a clear picture of how work happens today. A process map should show the trigger, people and systems involved, required data, approvals, hand-offs, exceptions and final outcome.

For example, manufacturing software should be assessed across the full flow: customer order or forecast; make-to-order (MTO), make-to-stock (MTS) or hybrid production; bill of materials (BOM); material planning; work-center execution; consumption, quality and output records; finished stock; delivery and finance.

Other businesses should map their own end-to-end flows, such as lead-to-cash, procure-to-pay, service-to-invoice, project-to-margin, or recruit-to-retire. The goal is to show where information crosses departments and where the work stops, repeats or depends on a spreadsheet.

Include employees who perform the work every day. A process described only by managers may miss workarounds that keep the operation running. A frontline user can explain why a field is sometimes blank, why an order is split, why a purchase is expedited, or why a customer receives a special approval. These details can affect system design, data migration and project estimates.

A useful process workshop asks:

• What starts the process, and what must be true before it can start?
• Who performs each step, and who can approve or change it?
• What data must be created, checked or shared?
• Which ERP, spreadsheet, machine, portal or other tool is involved?
• Where does work wait, repeat or need manual correction?
• What happens when the normal path fails?
• Which customer, legal, safety or financial rules apply, and how will success be measured?

The SIX approach to process analysis uses this kind of inquiry before configuration. SIX’s published transformation guidance says to review both formal steps and informal workarounds, map the current state, and then design a future state that removes unnecessary work instead of automating every old action. [6]

Define requirements that are tied to business outcomes

Process maps show how work moves. Requirements describe what the new system must enable. A good requirement is specific enough to test and linked to a business result, control, obligation or risk.

For example, “the system must have a production module” is too broad to guide a selection. A stronger requirement might be: “When a confirmed customer order creates a production requirement, the planner must be able to see the BOM demand, available stock, incoming purchase orders and planned work before releasing the work order.” That requirement can be demonstrated and tested.

Group requirements by importance and type:

Assign an owner to each requirement. The process owner should confirm the business need; the project team should record how the system meets it; and management should approve high-cost changes or accepted gaps. This prevents a feature list from becoming a collection of unranked wishes.

Requirements should also cover users, locations, response expectations, access, security, audit history, backup, reporting, retention, integrations and support. Include multiple legal entities, currencies, warehouses, production sites or languages early.

Decide what to standardize, configure, integrate or customize

A gap is a difference between the future process the business needs and the ERP’s standard capability. A gap is not automatically a reason to write custom software. First determine whether a standard process, configuration, a process change or a specialist integration can solve it.

Customization may be right when a process protects business advantage, safety, legal duties or customer commitments. Each custom feature needs an owner, business case, test and maintenance plan. It may also affect connected workflows, integrations, upgrades, training and support.

Microsoft’s fit-to-standard guidance recommends comparing current processes with standard ERP processes, documenting the gaps, and considering the cost, complexity and impact of proposed customizations before deciding. It also advises mapping the effect across connected processes, not only the process being changed. [7] The practical lesson is not “never customize.” It is “make each customization earn its place.”

Evaluate the product and the implementation partner together

Software capability is only part of the decision. The implementation partner’s approach, team, experience and support model can shape the result just as much. Assess both as one delivery choice.

Shortlist systems based on must-have requirements, industry needs, technical environment, data controls, deployment model and likely total cost. Then run the same business scenarios through each product. The vendor should identify whether each part is standard, configured, integrated or custom.

Eric Kimberling, an independent ERP adviser who writes on LinkedIn, puts the connection plainly: “ERP selection should never be viewed in isolation from implementation.” [1] That is a useful test for any selection process: are you assessing how the system will be delivered, migrated, tested and adopted—not only whether it looks capable in a presentation?

Build demonstrations around representative item lists, customer structures, BOMs, pricing rules, transaction volumes and exceptions. Protect sensitive production data with an appropriate agreement and data-handling plan; demo data should show real complexity without exposing private information.

Ask vendors to show:

• A normal transaction from beginning to end.
• A common exception, such as missing materials, a partial delivery or a rejected approval.
• How roles and permissions control what different users can do.
• How reports, audit records and traceability are produced.
• How the ERP works with the systems that will remain in place.
• What is included in the proposed product and licensing package.
• What requires configuration, development, third-party software or extra services.

Identify the actual project team: who leads discovery, solution design, migration, integrations and post-launch support? Request references from companies with similar processes. Ask how support and future changes are handled as the business grows.

Treat an early quote as an estimate until the work is understood

A vendor may provide an early budget range to help decide whether to continue, but it should be labelled preliminary and tied to clear assumptions.

A fixed implementation price requires a defined scope. Before a detailed proposal is treated as reliable, the vendor should understand the processes, users, sites, entities, data sources, transaction volumes, integrations, development requirements, testing needs, training and deployment plan. If many flows or individual customizations must be included, that discovery becomes even more important.

A price after a short sales conversation may assume clean data, simple integrations, available users, little custom development or identical site processes. If those assumptions are wrong, the project may need more budget, time or change orders, or less scope.

Be cautious of a vendor who gives a confident fixed implementation price before studying complex workflows or individual development needs. Ask the provider to show how the price relates to documented processes and deliverables. A responsible proposal should state:

• The processes, modules, companies and locations included.
• The required configuration, integrations and custom development.
• The data to be migrated and the client’s data responsibilities.
• The number and purpose of test cycles, training sessions and pilot activities.
• The implementation team and expected availability of client staff.
• The assumptions, exclusions, dependencies and acceptance criteria.
• The process for reviewing and pricing new or changed requirements.
• The post-launch support and stabilization arrangements.

LinkedIn practitioner Dani Kaplan specifically highlights discovery with actual users, review of representative data and written requirements before price is treated as final. [2] That recommendation is particularly relevant when a company has complex customer pricing, high transaction volume, unusual product data, production variants, or workarounds that have never been documented.

Plan migration as a business and data program

ERP migration is not simply a technical export and import. The old and new systems may use different definitions for customers, products, warehouses, accounts, units of measure, approvals or transaction status. Data needs to be cleaned, mapped, tested and reconciled. Business owners must decide what should move and what must remain accessible for reference.

Inventory the current ERP, spreadsheets, specialist applications, portals, machines and archives. Record each dataset’s owner, users, change frequency and business purpose.

Then classify the information:

Assign data owners and mapping rules. Decide how to handle duplicates, missing values, old codes and changed business structures. Reconcile key records after each migration test, such as financial balances or manufacturing stock, active BOMs and open work.

Do not assume that all historical data should be loaded into the live ERP. Some history may be needed for daily service or warranty work; other records may be available through a controlled archive. The company should choose based on operational, financial, audit and legal needs. Sam Gupta’s LinkedIn migration article also highlights master-data ownership, cleansing, historical data, reconciliation, rehearsals and archiving as areas to plan. [3]

Microsoft’s migration guidance similarly calls for an agreed data scope and strategy, field mapping and transformation, testing, validation and defined roles. [8]

Legacy records moving through data validation into connected ERP processes

Plan integrations, testing and cutover early

List each connection that must continue—accounting, payroll, e-commerce, portals, production equipment, banking, warehouse devices, transport or reporting. Record exchanged data, direction, timing, owner, failure handling and monitoring. Test real transaction volumes, unusual data and temporary outages.

Testing should follow complete business flows, not stop when an order or work order is entered. Verify data, permissions, reports and financial records across normal and difficult cases.

For example, a manufacturing scenario might test an order that requires a product variant, has a material shortage, needs a purchase order, moves through multiple work centers, records actual consumption, passes a quality check and produces finished stock for delivery and invoicing. A field-service scenario might test a booking change, a technician’s parts consumption, customer approval and invoice creation.

Plan cutover as a business event. Define who freezes the old system, when final data is extracted, which open transactions are loaded, who checks totals, who grants access, and how users report urgent issues. Rehearse the cutover in a test environment with the people and tools expected to take part. Agree on a go/no-go decision and a contingency plan before launch.

Microsoft’s implementation guidance recommends a tested cutover plan with clear tasks, owners, verification, sign-off and rollback planning. [9] The exact strategy—single go-live or phased rollout—should depend on system dependencies, business risk, seasonality, staff capacity and the ability to operate during transition.

Prepare people for the change

An ERP changes responsibilities and routines. Users may enter data differently, follow new approvals or stop relying on spreadsheets. Without explanation and practice, they may create workarounds outside the system.

Involve key users early. Train each role on real tasks, showing how the user’s work affects the next team and downstream records.

Managers should reinforce the agreed process, make timely decisions and help remove barriers. The project should also plan temporary productivity loss during learning. A short dip may happen as people learn the new system; good preparation and responsive support can help the business stabilize.

Measure adoption and business results after launch. Examples include order processing time, stock accuracy, number of duplicate entries, production plan accuracy, invoice cycle time, open support requests and use of the agreed ERP process. Compare these with the baseline defined before the project.

Employees and a project lead working through a new ERP flow in a live operation

The SIX 7-Step Consultation Flow

The SIX 7-Step Consultation Flow provides a structured path from initial direction through adoption. It can be used to organize ERP selection, migration and implementation planning. The steps are Set direction, Map today, Priorities gaps, Design tomorrow, Prepare, Plan delivery and Drive adoption. [5]

1. Set direction

Agree on the business reason for change before choosing an ERP. Define which companies, sites, teams and processes are included. Select a few measurable outcomes and assign owners who can make decisions. A clear direction helps keep vendor conversations focused on business needs instead of attractive but unrelated features.

2. Map today

Work with people across departments to map current processes, systems, data sources, reports, approvals and workarounds. Record both the ordinary flow and the exceptions. This creates a shared view of where the current operation is working and where it loses time, control or information.

3. Priorities gaps

Compare what the business needs with what current or candidate systems can support. Rank gaps by their effect on customers, operations, cost, risk, compliance and future growth. This is where the company decides whether a gap needs process change, configuration, integration, custom development or a later project phase.

4. Design tomorrow

Design the target process before configuring the software. Define who does each step, what data is needed, what approvals apply and how information moves between business areas. The target flow should be workable for employees and clear enough to test. It should improve the operation, not merely copy the old process into a new interface.

5. Prepare

Identify data owners, migration scope, integration requirements, key users, training groups and unresolved decisions. Start data cleanup early. Review sample records with the vendor or implementation partner. Preparation gives the project a more realistic view of effort and reduces surprises during build and testing.

6. Plan delivery

Turn the agreed scope into a roadmap with phases, owners, dependencies, test points and success measures. Decide whether to use a pilot, staged rollout or a broader cutover. Set rules for changes to scope. A delivery plan should state what the company and provider each need to supply, so the schedule and price have a clear basis.

7. Drive adoption

Support users after go-live and review whether the new flows are being used as designed. Track results, resolve problems and priorities improvements. Go-live is a transition point, not the end of the ERP program. SIX presents this seven-step model as a structured route from setting direction and mapping processes to data preparation, delivery and adoption. [5][6]

Common ERP selection and migration pitfalls

A practical checklist before signing

Before you select the ERP and sign an implementation agreement, make sure the project team can answer these questions:

• What business problem are we solving, and how will we measure progress?
• Have we mapped the actual current process, including exceptions and workarounds?
• Have the employees who do the work reviewed the target process?
• Are must-have requirements ranked and owned by named business stakeholders?
• Have we tested realistic end-to-end scenarios in each shortlisted system?
• Can the vendor identify what is standard, configured, integrated and custom?
• Have we reviewed representative data and documented migration responsibilities?
• Are required integrations, testing, training and support included in the plan?
• Does the proposal state assumptions, exclusions, dependencies and change-control rules?
• Do we understand total project effort and ongoing costs, not only the license?
• Is there a tested cutover plan, a go/no-go decision and a contingency approach?
• Is post-launch support planned for the period when users are learning the new flows?

Conclusion: Choose the ERP that fits the way your business should work

A successful ERP decision is a structured assessment of what the business needs, what systems support, which processes should change and how the company will move to a new way of working.

For an existing ERP, migration is a chance to decide what to preserve, improve, integrate, archive or retire. The goal is to give employees reliable flows, management clearer information and the business a system it can continue to develop.

At SIX, the 7-Step Consultation Flow starts with direction and process analysis, then moves through priorities, future design, preparation, delivery planning and adoption. This means the conversation can begin with the business itself—its processes, data, people and systems—before decisions about configuration, individual development and project pricing are finalized.

The right ERP project begins when the company can explain what it needs to improve, how its work flows today and what a better flow should look like tomorrow.

Talk to a SIX ERP expert about analyzing your business flows before selecting or migrating your ERP.

References

[1] Eric Kimberling, “Avoiding the Most Common ERP Software Selection Mistakes,” LinkedIn, June 7, 2025. https://www.linkedin.com/pulse/avoiding-most-common-erp-software-selection-mistakes-eric-kimberling-xb4kc/

[2] Dani Kaplan, “The Steps That Should be Taken Before Selecting New ERP Software,” LinkedIn, August 4, 2026. https://www.linkedin.com/pulse/practical-requirements-buying-new-erp-software-guide-dani-kaplan-kvkdc/

[3] Sam Gupta, “Migrating from Legacy ERPs: What Most Organizations Underestimate,” LinkedIn, August 22, 2026. https://www.linkedin.com/pulse/migrating-from-legacy-erps-what-most-organizations-sam-gupta-nqzgc/

[4] Chris Doig, “ERP Failure Begins Well Before the Software Is Selected,” LinkedIn, August 4, 2026. https://www.linkedin.com/pulse/erp-failure-begins-well-before-software-selected-chris-doig-16esc/

[5] SIX ERP, “Services Overview: The SIX 7-Step Consultation Flow.” https://six.ms/services-overview/

[6] SIX ERP, “From Spreadsheets to a Connected Business Transformation.” https://six.ms/blog/business-transformation-done-right/

[7] Microsoft Learn, “Optimize your implementation by using fit-to-standard and fit-gap analysis.” https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/process-focused-solution-fit-to-standard-fit-gap-analysis

[8] Microsoft Learn, “Manage configuration and migration data for Dynamics 365 projects.” https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/data-management-configuration-data-migration

[9] Microsoft Learn, “Transition to new solutions successfully with the cutover process.” https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/prepare-go-live-cutover-strategy

[10] SAP, “ERP Implementation Best Practices.” https://www.sap.com/resources/erp-implementation-best-practices