We completed our ERP migration last month. Eighteen months from vendor selection to go-live. We moved from on-premises SAP to a modern cloud ERP platform. The project came in slightly over budget and about two months behind schedule.

Everyone involved is exhausted. The project consumed massive resources and was often frustrating. But we’re now on a modern platform that better supports our business. It was worth the pain.

Here are the lessons we learned from this migration that might help others considering similar moves.

Why We Left SAP

Our SAP instance had been running for over a decade. It worked, mostly. But maintaining it was expensive and complex. We had heavy customisations that made upgrades difficult. Our SAP team was small and specialised, creating knowledge concentration risk.

SAP’s cloud offering was one option, but the migration path was complex and the cost was high. We evaluated cloud alternatives and found several that met our needs at lower total cost of ownership with simpler operational models.

The business case for migration was compelling. Lower licensing costs, reduced infrastructure expenses, elimination of customisation maintenance burden, and better integration capabilities with our other cloud systems.

The challenge was getting from here to there without disrupting business operations. ERP systems are foundational. Getting migration wrong creates existential risk.

Vendor Selection Took Longer Than Expected

We evaluated five ERP vendors over six months. Demos, proof of concepts, reference calls, cost modelling. The evaluation was thorough but time-consuming.

The vendors all looked similar in demos. They could all handle our core requirements. The differences came out in detailed evaluation of edge cases and integration scenarios.

We ultimately chose based on three factors. First, the platform’s architecture aligned with our cloud-first strategy. Second, the implementation partner had strong references doing similar migrations. Third, the total cost of ownership was substantially lower than alternatives.

Price wasn’t the primary factor but it mattered. We’re spending about forty percent less on the new platform than we spent on SAP when you include licensing, infrastructure, and support costs. That savings funded the migration project.

Implementation Was the Hard Part

We contracted with an implementation partner who specialised in migrations from SAP to our chosen platform. They had methodology, templates, and experience that we lacked internally.

The implementation followed standard phases. Discovery and requirements, design, configuration, data migration, testing, training, and go-live. On paper it looked straightforward. In practice it was messy.

Discovery took twice as long as planned because our SAP instance had evolved over years and documentation was incomplete. Understanding our actual business processes versus what SAP technically did required extensive workshops with business users.

We discovered that many processes existed because of SAP’s limitations rather than actual business needs. Users had built workarounds for things SAP couldn’t do well. We had to distinguish between genuine requirements and artifacts of our old system.

Configuration was iterative. Initial designs needed revision once business users saw working prototypes. Requirements that seemed clear in workshops became ambiguous when users interacted with the actual system. We went through three major design iterations before settling on final configuration.

Data Migration Was Painful

Moving a decade of transactional data from SAP to the new platform was technically complex and risky. Data formats differed. Business rules changed. Historical data had quality issues that needed cleaning.

We took a phased approach. Master data first, then historical transactions, then in-flight transactions near go-live. Each phase required extensive validation to ensure data transferred accurately.

We discovered data quality problems we hadn’t known existed. Duplicate customer records. Invalid product data. Inconsistent coding across years. Cleaning this data added months to the timeline.

The final data migration during go-live weekend was the most stressful part of the entire project. We had limited cutover window. Data needed to transfer completely and accurately. We ran parallel validation checks and had rollback plans, but the risk was real.

It worked. Data migrated successfully and validation checks passed. But those forty-eight hours were brutal for the team.

Change Management Was Critical

ERP systems touch every part of business operations. Finance, supply chain, manufacturing, sales. Everyone’s workflows changed with the new system.

We invested heavily in change management. Communication about what was changing and why. Training programs for different user roles. Hands-on practice time in test environments. Support resources for go-live.

Despite this investment, go-live was rocky. Users struggled with new interfaces and different workflows. The help desk was overwhelmed with questions. Some business processes were slower initially as people learned the new system.

We should have invested even more in change management. In retrospect, training and communication were more important than we appreciated. The technology migration succeeded but user adoption lagged because people weren’t adequately prepared.

Integration Required Custom Development

The new ERP platform had standard integrations with many systems, but several of our applications required custom integration development. Our warehouse management system, customer portal, and business intelligence platform all needed custom work.

We underestimated this effort. Integration work added four months to the timeline and substantial cost. Each integration was a mini-project with its own requirements, development, testing, and deployment.

The lesson is to assume integration will be harder and take longer than vendors claim. They demo integrations using ideal scenarios. Your specific environment will have complexities the demo didn’t cover.

Customisation Discipline Was Important

One of our goals was to reduce customisation compared to our heavily customised SAP instance. We established a rule: configure before customise. If the platform can do something through configuration, we use that capability even if it’s different from our old process.

We only agreed to customisation when the platform truly couldn’t support a critical business requirement through configuration. This discipline forced us to adopt more standard processes and reduced future maintenance burden.

It was difficult. Business users wanted the new system to work exactly like the old system. We had to push back and explain why adopting standard processes was better long-term even though it required changing habits.

This discipline paid off. Our new platform has far less customisation than our old SAP instance. Upgrades will be simpler. Support will be easier. The platform works more like the vendor designed it, which means better support and more predictable behavior.

Go-Live Strategy Mattered

We chose a “big bang” go-live rather than phased rollout. Everything cutover to the new system simultaneously over a weekend. The alternative was to migrate business units or modules sequentially over months.

Big bang was riskier but cleaner. We avoided months of parallel operation with dual systems. Users didn’t have confusion about which system to use for what. The pain was intense but brief.

We had extensive rollback planning. If the go-live failed, we could revert to SAP. We practiced the rollback procedure multiple times. Having this safety net gave everyone confidence to proceed.

The go-live weekend was stressful but successful. We had all hands on deck supporting the cutover. Minor issues emerged but nothing requiring rollback. By Monday morning we were operational on the new platform.

Post-Go-Live Support Was Essential

The first month after go-live was almost as resource-intensive as the migration itself. Users needed extensive support as they learned new workflows. We discovered configuration issues that weren’t caught in testing. Performance tuning was needed for some processes.

We maintained augmented support staffing for six weeks post go-live. This was critical for user confidence and adoption. Having experienced people available to answer questions and solve problems quickly prevented frustration from turning into resistance.

We also ran daily standup meetings to triage issues and coordinate fixes. This kept the team aligned and ensured problems got resolved quickly. Communication and coordination were as important as technical problem-solving.

The Results

We’re now three months post go-live. The system is stable. Users are comfortable with new workflows. Business processes are running smoothly. The crisis phase is over.

The benefits are starting to appear. Financial close is faster because processes are more automated. Integration with other systems is better. Reporting is more flexible. We’re doing some things that weren’t possible with our old SAP system.

The cost savings are real. Our annual operating costs for ERP are substantially lower than before. The migration paid for itself in about three years based on ongoing savings.

Was it worth it? Yes. But barely. ERP migrations are expensive, disruptive, and risky. We succeeded because we planned well, resourced adequately, and had good implementation partners. It could easily have gone worse.

Advice for Others

If you’re considering ERP migration, especially from SAP to cloud alternatives, here’s what I’d emphasise.

Invest heavily in discovery and requirements. Understanding your current state accurately is essential. Don’t rush this phase.

Choose implementation partners carefully. Their experience and methodology matters more than you think. Check references thoroughly.

Plan for data migration to take longer and be harder than expected. Data quality issues will emerge. Build in time to address them.

Invest more in change management than feels necessary. User adoption determines success or failure more than technical implementation.

Be disciplined about customisation. Adopt standard processes where possible even when users resist. Your future self will thank you.

Plan go-live carefully with extensive preparation and rollback capabilities. The cutover is the highest-risk moment of the entire project.

Maintain robust support post go-live. Users need help adapting to new systems. This support determines whether migration succeeds in users’ perception.

Finally, be patient. ERP migrations take eighteen to twenty-four months typically. Anyone promising faster delivery is either dealing with a much simpler environment or overselling. Set realistic expectations and plan accordingly.