The ERP system powering your £20M business was implemented in 2009. It works—mostly. But it's showing age:
- Cloud integration requires expensive middleware- Mobile access doesn't exist- The original vendor was acquired twice; support is minimal- Three employees understand how it works; two are retiring soon- API documentation is a myth; everything is manual integration
You need to modernise. But the last ERP replacement (a competitor) took 18 months, cost £2M, and nearly destroyed the business. The fear is real.
This is the legacy modernisation dilemma facing UK SMEs. Research from Gartner shows 72% of mid-market firms run business-critical systems over 10 years old, yet 65% of modernisation projects fail or significantly overshoot budget.
The good news: There's a better way than "rip and replace."
The Modernisation Decision Framework
Not all legacy systems need replacing. Start with strategic assessment.
Decision 1: What's Actually Broken?
Common Complaints (Not All Valid Reasons to Replace):
"It's old" → Age alone isn't a problem if it works"It's not cloud" → On-premise can be cheaper for stable workloads"Users complain" → Often a training issue, not a system issue"We can't hire developers who know it" → Migration costs more than maintaining expertise
Valid Reasons to Modernise:
Business Capability Gap- Can't support new business models (e.g., subscription billing when system only handles one-time sales)- Can't scale to growth targets (performance degrades beyond certain volume)- Can't serve new markets (no multi-currency, multi-language support)
Technical Risk- Security vulnerabilities with no patches available- Compliance failures (GDPR, industry regulations)- Vendor discontinued product; end-of-life imminent
Economic Pressure- Maintenance costs >40% of replacement TCO- Integration costs >£100K annually to keep functioning- Business opportunity cost >£500K annually (deals lost due to system limitations)
Decision 2: Modernise or Replace?
The Modernisation Spectrum:
Option 1: Retain (Do Nothing)- When: System meets all needs, no compelling business case for change- Risk: Technical debt accumulates, becomes crisis eventually- Best for: Systems with <5 year remaining lifespan before natural replacement
Option 2: Encapsulate (API Wrapper)- When: Core functionality solid, but integration is painful- Approach: Build API layer around legacy system (expose data/functions via modern APIs)- Cost: £30K-£80K- Best for: Systems with business logic you want to preserve
Option 3: Rehost ("Lift and Shift" to Cloud)- When: Technical infrastructure outdated, application logic fine- Approach: Move to cloud VMs with minimal changes- Cost: £50K-£150K- Best for: Datacentre exit, disaster recovery improvement
Option 4: Replatform (Hybrid Modernisation)- When: Some components salvageable, others not- Approach: Modernise piece-by-piece (database to cloud, keep application)- Cost: £100K-£300K- Best for: Gradual modernisation, budget constraints
Option 5: Replace (New System)- When: Fundamental business model change or complete technical obsolescence- Approach: Implement modern replacement- Cost: £200K-£2M+- Best for: System can't support strategy, modernisation costs approach replacement
Decision 3: Big Bang or Incremental?
Big Bang Replacement:- Switch entire system on "go-live" weekend- Pros: Clean break, no integration complexity- Cons: High risk, business disruption if failure-Failure rate: 45%
Incremental Modernisation:- Replace components over 12-24 months- Pros: Lower risk, business continuity- Cons: Integration complexity, longer timeline-Failure rate: 18%
For SMEs: Incremental is safer—unless system is completely unusable
The Strangler Fig Pattern
The safest modernisation approach: Gradually replace legacy with new, side-by-side.
Named after strangler fig trees that grow around host trees, eventually replacing them.
Phase 1: Establish the New Alongside the Old (Months 1-3)
The Architecture:
```[Users] → [Routing Layer] → [Legacy System] (existing functionality) ↘ [New System] (new functionality only)```
Implementation:1. Deploy new system2. Route NEW functionality to new system3. Route EXISTING functionality to legacy (unchanged)4. No immediate migration required
Example: E-Commerce Platform
Month 1: New system handles product catalogue (modern, cloud-based)Legacy: Still processes orders, payments, inventory
Risk: Minimal (new features in new system, existing features untouched)
Phase 2: Migrate Function-by-Function (Months 3-18)
Incremental Migration Strategy:
The Priority Order:
Wave 1: New Features (Months 3-6)- Build all new capabilities in new system- Never enhance legacy (it's dying)- Users gradually interact more with new system
Wave 2: Least Critical Functions (Months 6-9)- Migrate non-critical but frequently used features- Low business risk, high learning value- Examples: Reporting, admin functions, lookup tables
Wave 3: Core Functions (Months 9-15)- Migrate business-critical functionality- Extensive testing, staged rollout- Examples: Order processing, inventory management
Wave 4: Complex Integrations (Months 15-18)- Final integrations, edge cases- Decommission legacy system
The Routing Pattern:
```[Users] → [Smart Router] → 70% New System ↘ 30% Legacy System
(Percentage shifts over time: 30%→50%→80%→100% new)```
Benefits:- Rollback capability (if migration fails, route back to legacy)- Parallel testing (validate new system against legacy)- User acclimatisation (gradual change, not shock)
Phase 3: Data Migration (Ongoing)
Data is the hardest part of modernisation.
The Data Migration Strategy:
Approach 1: Trickle Migration- Migrate data as it's accessed (lazy loading)- User requests record → check new system → if not present, migrate from legacy- Pros: No big-bang data migration- Cons: Dual-system overhead during transition
Approach 2: Bulk Migration (Staged)- Migrate data in batches (by date range, customer segment, product category)- Weekend migration windows- Pros: Cleaner cutover- Cons: Requires downtime, complex synchronisation
Approach 3: Hybrid (Recommended for SMEs)- Bulk migrate historical data (non-changing records)- Trickle migrate transactional data (orders, invoices being modified)- One-way sync: Legacy → New (for transition period)
Critical Success Factors:
Data Quality Cleansing:- Legacy data is dirty (duplicates, inconsistencies, incomplete records)- Clean during migration, not after- Budget 30-40% of migration effort for data quality
Validation:- Compare record counts (did everything migrate?)- Sample testing (random records match?)- Reconciliation (financial totals match?)
Rollback Plan:- Keep legacy operational for 90 days post-migration- Ability to reverse migration if critical issues found
The API-First Integration Strategy
Modern systems integrate via APIs. Legacy systems... don't.
The Integration Hierarchy:
Level 1: Direct Database Access (Legacy Approach)- New system reads/writes directly to legacy database- Pros: Simple, no middleware- Cons: Brittle (schema changes break integration), no business logic enforcement-Use only as temporary bridge
Level 2: Middleware/Integration Platform- Integration tool (MuleSoft, Boomi, Talend) connects systems- Pros: Handles transformation, orchestration- Cons: Cost (£30K-£100K annually), complexity-Best for: Complex integrations, multiple systems
Level 3: API Wrapper- Build REST/GraphQL APIs around legacy system- Pros: Exposes legacy as modern service, decouples integration- Cons: Development effort (£40K-£80K)-Best for: Long-term legacy retention, multiple consumers
Level 4: Event-Driven Architecture- Systems communicate via event bus (Kafka, RabbitMQ)- Pros: Real-time, decoupled, scalable- Cons: Operational complexity, cultural shift-Best for: High-volume, real-time requirements
For SME Modernisation: Start with Level 2 (middleware), evolve to Level 3 (APIs)
The Change Management Imperative
Technology is 40% of modernisation. People are 60%.
User Adoption Strategy
Phase 1: Early Engagement (Months 1-3)- Form user advisory group (8-12 power users across departments)- Involve in requirements gathering- Preview new system, collect feedback- Build champions who advocate for change
Phase 2: Pilot Users (Months 6-9)- 10-15% of users on new system first- Volunteers (enthusiastic) + sceptics (need convincing)- Intensive support, rapid issue resolution- Success stories shared company-wide
Phase 3: Phased Rollout (Months 9-15)- Department-by-department or function-by-function- 2-week gaps between rollouts (time to stabilise)- Dedicated support for first week post-rollout
Phase 4: Full Adoption (Months 15-18)- All users migrated- Legacy system read-only (30 days)- Legacy system decommissioned (after final data validation)
Training Approach
Not "Big Training Event"—Continuous Learning:
Pre-Go-Live:- Role-based training (3-4 hours per user)- Hands-on practice environment- Job aids (quick reference guides)
Go-Live Week:- Floor support (trainers on-site, helping users)- War room (rapid issue triage and resolution)- Daily standups (what's working, what's breaking)
Post-Go-Live:- Office hours (weekly Q&A sessions)- Video library (short how-to clips)- Power user network (peer support)
Budget: 15-20% of project cost for change management
The Cost Reality
Total Cost of Modernisation (£15M SME, Core ERP Replacement):
Technology Costs:- New system licensing: £60K-£150K (first year) + £35K-£80K annually- Implementation services: £150K-£400K- Data migration: £40K-£80K- Integration: £60K-£120K- Infrastructure (cloud): £25K-£50K annually-Total Technology: £335K-£800K
People Costs:- Project management (internal): £80K (1 FTE, 12 months)- Business analysis: £60K- Training development: £30K- Change management: £50K-Total People: £220K
Risk/Contingency:- Overruns, scope changes: 20-30% of budget-Contingency: £110K-£200K
Total Modernisation Investment: £665K-£1.22M
Comparison to "Do Nothing" Cost (5 years):- Maintenance: £100K/year = £500K- Integration workarounds: £60K/year = £300K- Opportunity cost (lost deals, inefficiency): £150K/year = £750K-Total "Do Nothing" Cost: £1.55M
Modernisation ROI: 27-133% over 5 years
The Vendor Selection Framework
Choosing the Right Replacement System:
Evaluation Criteria
Functional Fit (40% weighting):- Meets 80%+ of requirements out-of-box- Configurable (not customisable—customisation is technical debt)- Industry-specific features vs. generic
Technical Architecture (25% weighting):- Cloud-native (true SaaS, not hosted legacy)- API-first design- Modern tech stack (5-year future-proof minimum)- Mobile-responsive
Vendor Viability (20% weighting):- Financial stability (profitable or funded for 3+ years runway)- Customer base (300+ installations in your size/industry)- Product roadmap (active development, quarterly releases)- Support quality (response SLAs, user community)
Total Cost of Ownership (15% weighting):- 5-year TCO (not just license cost)- Implementation complexity (simple = lower cost)- Training requirements- Integration costs
The RFP Process:
1.Requirements Gathering (4 weeks): Document must-haves vs. nice-to-haves2.Long-list (2 weeks): Identify 8-12 potential vendors3.Short-list (4 weeks): RFP to 4-5 vendors, demos, reference calls4.Deep Dive (4 weeks): Finalist demos (3-4 hours each), technical due diligence5.Negotiation (2-4 weeks): Commercial terms, implementation approach6.Decision (1 week): Board approval, contracts signed
Total: 17-19 weeks from start to vendor selection
Common Modernisation Mistakes
Mistake 1: Underestimating Data MigrationAssuming data is clean and migration is simple. Reality: 40% of project effort is data.
Mistake 2: Like-for-Like ReplacementReplacing old system with new system doing exactly the same thing. Missed opportunity to improve processes.
Mistake 3: Customisation CreepCustomising new system to match legacy quirks. Creates technical debt in new system.
Mistake 4: Ignoring Change ManagementFocusing only on technology, neglecting user adoption. Result: System works, nobody uses it.
Mistake 5: No Rollback PlanAssuming migration will succeed. Reality: 30% of cutovers have critical issues requiring rollback.
The Modernisation Roadmap
Month 1-3: Strategy & Planning- Business case development- Modernisation approach selection (strangler fig, replace, etc.)- Vendor selection (if replacing)- Project team formation
Month 4-6: Foundation- Requirements finalisation- New system procurement- Integration architecture design- Change management planning
Month 7-12: Build & Pilot- New system implementation- First functionality migration (strangler fig)- Pilot user group (10-15%)- Data migration testing
Month 13-18: Rollout- Phased user migration- Function-by-function cutover- Legacy system deprecation- Final data migration
Month 19-24: Optimisation- Legacy decommissioning- Process improvement (now that new system enables it)- Advanced feature adoption- ROI measurement
Total: 24-month journey from decision to full adoption
The Success Metrics
Track These Throughout Modernisation:
Technical Health:- System uptime: >99.5%- Performance: Page load <2 seconds- Integration reliability: >99% success rate- Data quality: <0.5% error rate
User Adoption:- Active users: >95% of licensed users- Feature utilisation: >60% of key features used- Support tickets: <2 per user per month- User satisfaction: NPS >30
Business Value:- Process efficiency: 20-40% time savings- Error reduction: 50-70% fewer mistakes- Cost savings: TCO reduction 15-30%- Revenue enablement: New capabilities generating £X
Project Delivery:- On-time: ±10% of plan- On-budget: ±15% of budget- Scope delivered: >90% of committed features
The Build vs. Buy Decision
Should you build custom vs. buy off-shelf?
Buy Off-Shelf When:- Industry-standard processes (accounting, HR, CRM)- Proven solutions exist (300+ companies using successfully)- Time to value critical (need solution in 6-12 months)- Limited IT capacity (can't build and maintain)
Build Custom When:- Unique competitive advantage (process is your secret sauce)- No suitable solutions exist (very niche requirements)- Integration is simple (standalone system)- Long-term investment (10+ year horizon)
For 90% of SME core systems: Buy. For 10% competitive differentiators: Build.
The Philosophical Question
Is your legacy system a liability or an asset?
If it constrains strategy, increases risk, or costs more to maintain than replace—it's a liability. Modernise.
If it works reliably, supports growth, and team expertise is strong—it's an asset. Optimise, don't replace.
The trap: Emotional attachment to systems because "we've always used them."
The market doesn't care about your history. It cares about your capability.
Modern systems enable modern business models. Legacy systems are anchors to past ways of working.
The choice is binary: Modernise to compete, or decline gracefully.
Most SME leaders choose modernisation—eventually. The successful ones choose it before crisis forces their hand.
The time to modernise is when you can afford to do it properly, not when desperation demands shortcuts.