ERP migrations are among the riskiest IT projects a business will ever undertake. Budget overruns, schedule slippage, scope creep, and underestimated change management — the pitfalls are well-documented. Industry analysts (Gartner, Panorama Consulting, Standish Group) consistently find that a significant majority of ERP migrations exceed their original budget or timeline.
Yet for many organisations, migrating is no longer optional: ageing technology, end of vendor support, business growth, and regulatory mandates (e-invoicing, ESG reporting, data residency) all force the issue. A methodical approach is what separates a quiet success from a very public failure.
Why Your Organisation Needs to Migrate Its ERP
1. Critical Technical Obsolescence
Warning signs that cannot be ignored:
- End of vendor support announced (as with Windows 10, Office 2019, or older ERP releases)
- Ageing infrastructure: on-premise servers running unsupported operating systems or databases
- Unpatched security vulnerabilities the vendor no longer fixes
- Regulatory incompatibility: GDPR, mandatory e-invoicing, ESG disclosure requirements
Real-world example: A mid-market manufacturer has been running SAP R/3 since 2008. SAP announces end of mainstream maintenance for 2027. The company has 18 months to migrate to S/4HANA or switch to an alternative ERP.
2. Business Growth Hitting a Ceiling
Telling symptoms:
- Degraded performance: reports that take hours to run
- Licence cost spiral: prohibitive costs to add more users
- Missing capabilities: no e-commerce, mobile, or modern BI
- Integration dead-ends: no APIs, obsolete connectors
3. Maintenance Costs Crowding Out Innovation
The 80/20 rule inverts — and that inversion is a serious warning signal:
- The share of the IT budget consumed by keeping the lights on becomes dominant
- The share available for new projects and innovation shrinks to almost nothing
- Annual maintenance spend approaches or exceeds a material fraction of the original licence cost, year after year
If you have observed this drift in your IT budget over two or three consecutive years, your ERP has become a drag on the business rather than an enabler.
Three ERP Migration Strategies
Strategy 1: Lift & Shift (Technical migration)
Principle: Modernise the platform without touching the processes
Example: Dynamics NAV on-premise → Dynamics 365 Business Central cloud
- Duration: 3–6 months
- Risk: Low
- Benefit: Technical only
When to use it: Imminent end of support, processes already well-optimised
Strategy 2: Optimisation (Migration + improvement)
Principle: Change ERP while streamlining key processes
Example: SAP Business One → Odoo with improved workflows
- Duration: 6–12 months
- Risk: Moderate
- Benefit: Technical + operational
When to use it: Moderate need for functional evolution
Strategy 3: Transformation (Migration + redesign)
Principle: Completely rethink the organisation around the new ERP
Example: Legacy ERP → SAP S/4HANA with full digitalisation
- Duration: 12–24 months
- Risk: High
- Benefit: Full business transformation
When to use it: Strong growth phase, fundamental business model change
7-Phase Migration Methodology
Phase 1: Audit and Strategy (4–6 weeks)
Objectives:
- Audit the current ERP (technical and functional)
- Analyse data to be migrated
- Define the target and migration strategy
Key deliverables:
- Full inventory of data and processes
- Requirements document for the new ERP
- Detailed migration plan
- Budget and timeline
Example discovery output:
Current ERP: Dynamics NAV 2016
- 15,000 items, 3,500 customers, 850 suppliers
- 5 years of financial and commercial history
- 12 concurrent users
- 45 critical custom reports
- Interfaces with 6 third-party applicationsPhase 2: Target Selection (6–8 weeks)
Approach:
- Shortlist: 3–5 candidate ERPs
- Functional workshops: 2 days per vendor
- Test on real data: demonstration environment with your own dataset
- Comparative analysis: weighted scoring grid
- Negotiation: contract and commercial terms
Example scoring grid:
| Criterion | Weight | ERP A | ERP B | ERP C |
|---|---|---|---|---|
| Functional fit | 35% | 8/10 | 9/10 | 7/10 |
| Technical | 25% | 7/10 | 8/10 | 9/10 |
| 3-year TCO | 20% | 6/10 | 8/10 | 7/10 |
| Implementation support | 20% | 9/10 | 7/10 | 8/10 |
| Weighted total | 7.4 | 8.1 | 7.6 |
Phase 3: Preparation (8–12 weeks)
Technical architecture:
- Infrastructure provisioning (servers, network, backups)
- Target ERP installation and configuration
- Base setup (structure, users, permissions)
- Migration tooling (ETL, custom scripts)
Data preparation:
- Cleansing: duplicates, stale records, inconsistencies
- Mapping: old-to-new field correspondence
- Transformation: format, codes, reference data
- Validation: automated quality checks
Cleansing example:
- 15,000 items → 12,500 after de-duplication
- 3,500 customers → 2,800 active customers retained
- 45 custom reports → 23 migrated + 15 replaced by standard reports
Phase 4: Data Migration (4–6 weeks)
Progressive approach:
Sprint 1: Reference data
- Items, customers, suppliers
- Chart of accounts, price lists
- Business configuration
Sprint 2: Transactional history
- Orders, invoices, payments
- Stock records and movements
- Accounting data
Sprint 3: Advanced data
- Attached documents and emails
- In-flight workflows
- Reports and dashboards
Quality checks after each sprint:
# Example automated check
def check_customer_migration():
source_count = execute("SELECT COUNT(*) FROM old_customers WHERE active=1")
target_count = execute("SELECT COUNT(*) FROM new_customers")
if abs(source_count - target_count) > 10:
raise MigrationError("Customer count discrepancy > 10")
return f"✓ {target_count} customers migrated successfully"Phase 5: Testing and Validation (6–8 weeks)
Technical testing:
- Performance: response times, load testing
- Integrations: APIs, data exchanges, interfaces
- Security: access rights, encryption, backups
Functional testing:
- Business processes: sales, purchasing, stock, finance
- User journeys: order → invoice → payment
- Reports: reproduction of critical outputs
User acceptance testing:
- Key user training (2 days)
- Real-world testing (2 weeks)
- Formal acceptance review
- Go/No-Go decision
Phase 6: Deployment (2–4 weeks)
Deployment strategies:
Big Bang (recommended for SMEs)
- Freeze old ERP on Friday evening
- Final migration over the weekend
- Go live Monday morning
Phased rollout (large enterprises)
- Pilot entity → generalisation
- Process by process
- Site by site
Big Bang planning example:
Friday 18:00 Freeze data entry in old ERP
Friday 20:00 Final data export
Saturday 08:00 Automated migration run
Saturday 14:00 Quality checks and testing
Sunday 10:00 User training sessions
Monday 08:00 Production go-livePhase 7: Stabilisation (8–12 weeks)
Post-migration support:
- Reinforced helpdesk: available 7 days a week for the first 2 weeks
- On-site support: consultants on-site for the first 5 working days
- Top-up training: power users, new features
- Optimisations: fine-tuning, performance, automation
Measuring success:
- Uptime meeting your target SLA (minimum 99%)
- Response times within the thresholds defined in your requirements document
- Positive user satisfaction (measured on a representative sample)
- Return to normal productivity within a short timeframe (typically ~4 weeks)
Critical Mistakes to Avoid
1. Underestimating Data Quality
Mistake: “We’ll clean up the data after migration” Consequence: Inconsistent data → blocked processes → loss of user trust
Solution: Allocate a significant share of project time to data cleansing before migration. Count in weeks, not days — this phase is consistently underestimated.
2. Neglecting Change Management
Mistake: Focusing exclusively on the technical side Consequence: User resistance → low adoption → project failure
Solution: Budget a dedicated line for change management (training, communication, key users, post-go-live support). This is non-compressible.
3. Going Live During a Peak Period
Mistake: Migrating during a business-critical period Example: Migrating an e-commerce ERP during Black Friday, or a manufacturer’s ERP during year-end order rush Solution: Plan your go-live during a quiet business period, even if it means delaying the project by a few months.
4. An Untested Rollback Plan
Mistake: “It’ll work first time” Reality: It is common for a migration to require a temporary rollback on at least one scope — a module, a legal entity, or an interface that doesn’t behave correctly.
Solution: A tested rollback system (not just documented), activatable within a few hours, with a user communication plan ready to go.
Budget and ROI
Typical budget breakdown (indicative)
For an organisation with approximately 100 users (adjust for your target ERP and complexity):
| Line item | Share of budget |
|---|---|
| New ERP licences (or SaaS subscription over the contract term) | ~35% |
| Integration services (configuration, migration, development) | ~30% |
| Infrastructure (if on-premise) or technical integrations | ~15% |
| User and key user training | ~10% |
| Change management | ~5% |
| Contingency (non-negotiable) | ~5% |
Key takeaway: licences are only ~35% of total cost. Integration services are consistently the largest source of budget overrun. Do not be dazzled by an attractive licence price that hides understated integration costs.
How to calculate ROI realistically
Never rely on generic ROI figures (“+20% productivity”, “+86% over 3 years”) you find online. These numbers are marketing and correspond to no identifiable real-world company.
Realistic calculation method:
- Identify 3–5 specific gain areas relevant to you (e.g., reduce monthly close time, lower invoice error rate, improve working capital through better stock visibility).
- Estimate each area using your current figures (measured time, audited error rate, actual volumes).
- Project gains over 3 years using a conservative hypothesis (50–70% of the vendor’s stated target).
- Compare against full 3-year TCO (licences + services + infrastructure + training + maintenance).
A robust ROI is demonstrated, not promised.
Realistic Timeline by Organisation Size
| Organisation size | Users | Total duration | Critical phases |
|---|---|---|---|
| Micro-business | 5–10 | 4–6 months | Data migration (3 weeks) |
| SME | 10–50 | 6–9 months | User testing (6 weeks) |
| Mid-market | 50–200 | 9–15 months | Training (8 weeks) |
| Enterprise | 200+ | 15–24 months | Phased rollout (12 weeks) |
Migration Success Checklist
Before you start
- Project sponsor identified at board or executive level
- Budget approved with an explicit contingency line (at least 10–15%)
- Dedicated project team (project manager + key users)
- Schedule accounts for business peak periods
- All stakeholders aligned
During the migration
- Weekly progress reviews
- Automated quality checks at every stage
- Active user communication plan
- Load and performance testing
- Rollback plan tested and validated
After go-live
- Reinforced post-production support (4 weeks)
- User satisfaction measurement
- Performance optimisations identified
- Additional training scheduled
- Project debrief and lessons learned
Your Immediate Roadmap
Week 1: Express diagnostic
- Audit your current ERP: version, end-of-support date, limitations
- List your pain points: slowdowns, recurring bugs, missing features
- Assess urgency: end of support within 2 years = high priority
Weeks 2–3: Opportunity study
- Calculate the cost of doing nothing: maintenance, bugs, lost productivity
- Estimate migration budget: use the breakdown above
- Identify the benefits: productivity gains, new capabilities
Week 4: Go/No-Go decision
- Present the business case to leadership
- Secure executive sponsorship and provisional budget
- Issue the RFP for implementation partners
An ERP migration is not a technology project — it is a business transformation. With the right methodology and expert support, you can turn this challenge into a genuine opportunity for modernisation and growth.
Don’t wait for a crisis to act. A well-planned, controlled migration is always preferable to a forced migration under pressure.
