Migrating a legacy ERP to the cloud is one of those projects that sounds exciting on a slide deck and terrifying in the boardroom. I’ve led and advised on several ERP migrations, and the single objective that guides me every time is simple: move to the cloud without disrupting revenue or customer delivery. That goal forces a pragmatic, customer-first approach—because if your invoices stop going out, or shipments miss their windows, everyone notices immediately.
Start with a business-driven inventory, not a technical checklist
The first mistake I see teams make is starting with servers and databases. Instead, begin with processes and outcomes. Map the business processes the ERP supports: order entry, fulfillment, invoicing, procurement, production scheduling, returns. For each process, identify:
This lets you prioritize the modules and data sets that cannot tolerate downtime. If you only back up a few tables but not the order-to-cash flow, you haven’t protected revenue.
Choose a migration strategy aligned to risk appetite
There are several migration paths—lift-and-shift, replatform, refactor, or replace—and each has trade-offs.
| Strategy | Pros | Cons | When I recommend it |
|---|---|---|---|
| Lift-and-shift | Fast, lower upfront dev cost | Limited cloud-native benefits; may need follow-up work | When you need minimal disruption and limited change window |
| Replatform | Balances speed and optimization | Requires testing and some redevelopment | When you want immediate performance improvements |
| Refactor/Replace | Maximizes cloud benefits (scalability, microservices) | Longest timeline, highest initial cost | When you need long-term agility and can tolerate phased delivery |
I rarely recommend a full refactor all at once if customer delivery is on the line. Instead, adopt a phased approach: migrate the least risky components first, unlock quick wins, then tackle core revenue flows with validated patterns.
Design a cutover approach that protects revenue
There are three practical cutover patterns I use depending on tolerance for synchronization complexity:
Parallel runs are my preferred position when the business can afford the extra reconciliation overhead. They provide a safety net: if revenue flows fail in the cloud, fall back to the legacy system without customer impact.
Data migration: accuracy over speed
Moving data is where surprises hide. My checklist for data migration focuses on fidelity and operational continuity:
Remember that historical data volume matters. You may archive decades of transactional history into a read-only data lake (S3, Azure Data Lake) while keeping recent operational windows live in the ERP.
Protect integrations: the silent dependency
ERP systems rarely operate alone. They talk to carriers (tracking), banks (payments), ecommerce platforms, and third-party manufacturers. Every API is a potential failure point.
In one migration, we routed only 10% of ecommerce orders to the cloud ERP for two weeks and monitored fulfillment KPIs before increasing traffic—this incremental approach avoided a potentially catastrophic fulfillment backlog.
Operational readiness: runbooks, monitoring and rollback
Migrations become crises without operational playbooks. I create detailed runbooks for every step in the cutover, including:
Monitoring must be real-time and actionable. Set alerts for SLA breaches that matter—failed shipments, payment processing errors, or order acknowledgement delays. If you’re using AWS, services like CloudWatch and X-Ray help trace issues through the stack; Azure Monitor and Application Insights are similar for Microsoft-centric shops.
Security, compliance and licensing
Moving to the cloud is not an excuse to relax on security. I always align migration plans to compliance frameworks (GDPR, SOC 2, PCI-DSS where applicable). Key considerations:
Engage legal and security teams early to avoid last-minute compliance blockers that could delay cutover and affect revenue.
Engage people: training and stakeholder communication
Technology is only one half of the migration. People make or break the go-live. I run a communications cadence that includes:
During a prior migration, proactive training for customer support about how to read the new order statuses reduced inbound escalations by nearly 40% in the first month.
Choose vendors and partners who share your SLA obsession
Cloud hyperscalers (AWS, Azure, Google Cloud) provide reliable infrastructure, but the integration layer matters. If you use ERP vendors like SAP or Oracle, engage certified partners with proven cutover experience. Managed service providers can run the day-to-day post-migration while your team focuses on business processes.
Post-migration: validate business metrics, not just system health
After cutover, don’t declare victory on uptime alone. Validate business metrics:
If these KPIs drift, act fast. The cloud gives you agility—use it to deploy quick fixes, configuration changes, or temporary routing to the legacy system until permanent solutions are in place.
Finally, remember that migration is not a single event but a transformation journey. If you plan with revenue preservation and customer delivery at the center, you can use the cloud to become more resilient and competitive without putting your business at risk. I always say: the best migrations are the ones your customers never even notice.
