What actually happens when you rip out a legacy ERP across multiple continents
I spent three years overseeing an enterprise system rollout for a manufacturing company that operated in 14 countries. The project was supposed to take 18 months. It took four. The systems work fine now, but getting there required learning a lot of things the consultants never mention in their presentations. The core challenge isn't the technology. It's coordinating hundreds of stakeholders across time zones while simultaneously migrating live transactional data without stopping the business. Most failures happen in the gap between those two realities.
Transforming Global Operations The Enterprise System Implementation That Rebooted A Multinational Corporation
When we talk about transforming global operations through enterprise system implementation, we're really talking about replacing fragmented legacy platforms with a unified stack. SAP S/4HANA, Oracle Cloud, Microsoft Dynamics 365 — the specific vendor matters less than understanding what each module actually does under load. Here is how the process works in practice, not in theory.
Phase One: Discovery That Actually Matters
Most companies rush discovery. They send in consultants who spend two weeks interviewing people and produce a requirements document that becomes obsolete by the time anyone reads it. The right approach takes significantly longer. We spent eight weeks just mapping processes. Not the documented ones in the policy manual, the actual ones. The ones people use at 4pm on a Friday when everything is on fire. I learned this the hard way in 2019 when we were implementing a similar system for a logistics company in Southeast Asia. Their documented procurement process had 12 steps. The actual process had 47 steps, only three of which appeared in any official documentation. The other 44 involved workarounds that had accumulated over twelve years of the old system failing at specific points.
The workaround I still think about involves invoice reconciliation for a specific supplier in Vietnam. The legacy system couldn't handle their currency formatting correctly, so the AP team had manually adjusted entries in a separate spreadsheet before importing. When we migrated, we lost that spreadsheet. The first month of the new system had reconciliation errors on about 30 percent of those invoices. My fix was simple but costly in terms of time. We rebuilt the workaround as a proper integration layer using middleware. It cost an extra 60,000 euros and three weeks of development, but it prevented what would have been a catastrophic month-end close.
Get the Full Details
Phase Two: Architecture Decisions That Will Haunt You
The technical architecture choices you make in the first six months determine whether this project succeeds or becomes a ten-year nightmare. I am not exaggerating. Greenfield versus brownfield deployment is the first major decision. Greenfield means building the new system from scratch with clean data. Brownfield means migrating your existing data and customizations into the new platform. Brownfield is faster and cheaper upfront. It is also almost always the wrong choice for multinational implementations. You inherit all the technical debt from your old system. Bad master data. Inconsistent chart of accounts. Custom reports built on deprecated frameworks. When you migrate garbage, you get garbage faster, not garbage that is properly organized.
The second decision is decentralized versus centralized instantiation. Do you set up one central instance for the entire organization, or do you create regional instances that share a common platform but have local configurations? For a multinational corporation, the answer depends entirely on regulatory complexity. If you operate in countries with strict data residency requirements — India, China, Russia, Brazil — centralized is politically impossible. Even if the technology supports it, local compliance teams will block it. We ended up with a hybrid model. Central instance for Europe and North America. Regional instances for Asia-Pacific and Latin America. They all run the same platform version but with different localization packages. The integration between them uses standard API endpoints, not point-to-point connections that will break when someone changes a field name.
Phase Three: Data Migration — Where Projects Go to Die
Data migration is the single highest-risk activity in any enterprise implementation. I have never seen a project that finished on time because of data issues. I have seen projects that finished on time despite data issues, but the first six months were brutal. The standard approach involves extracting data from legacy systems, cleansing it, transforming it into the target format, and loading it into the new system. This sounds straightforward until you realize that your customer master data exists in seven different formats across four different countries, two of which are manual Excel spreadsheets. Our approach was iterative. We ran pilot migrations with limited data sets before attempting full cutover. Each pilot revealed different problems. The first pilot exposed that our vendor master data had 40 percent duplicate entries because different countries used different naming conventions for the same suppliers.
The second pilot revealed that our open purchase orders from the German operation contained line items that referenced materials that no longer existed in the new system's material master. Those references had to be resolved manually or the orders would fail on creation. By the fourth pilot, we had developed a standardized cleansing framework that reduced manual intervention to about 15 percent of records. That 15 percent required subject matter experts from each region to validate decisions about how to handle edge cases.
Phase Four: Testing That Actually Catches Problems
Most companies test their enterprise implementations inadequately. They write test cases based on happy-path scenarios and run them in isolation. This catches about 20 percent of the problems that will surface after go-live. Real testing requires integrated scenario testing across all modules and all regions simultaneously. You need to test a complete order-to-cash cycle that starts in Germany, involves a subsidiary in Mexico, gets paid through a bank in Singapore, and is consolidated in the European headquarters financials. We built a test environment that mirrored production exactly, including realistic volumes of data. This meant loading millions of records into the system before testing began, which added three weeks to the schedule but saved approximately six weeks of post-go-live debugging.
Integration testing with external systems is where most multinationals fail. Your new ERP needs to connect to legacy systems that nobody has updated documentation for, third-party platforms that have changed their APIs without warning, and custom applications that were built by contractors who no longer exist. One specific integration we struggled with was the connection to a warehouse management system in our Brazilian facility. The WMS was a custom Java application built in 2008. The interface documentation was a three-page Word document that didn't match the actual API. We spent two weeks reverse-engineering the integration before we could reliably test data flow between the systems.
Phase Five: Change Management — The Part Everyone Underestimates
Technical implementation is maybe 40 percent of the work. The remaining 60 percent is getting humans to use the new system correctly. Change management in a multinational context requires understanding that resistance looks different in every culture. In Germany, resistance manifests as detailed questions about compliance and documentation. In Brazil, it manifests as social networks of people who refuse to adopt the new process through informal channels. In Japan, resistance is often silent — people pretend to comply while continuing old workarounds. We appointed change champions in every location. These were not managers. They were individual contributors who had genuine influence over their peers. The difference matters because formal authority rarely changes behavior in complex organizations.
Training was another area where we learned through painful experience. The initial training program was a series of four-hour workshops covering every module. Attendance was mandatory. Completion rates were high. Actual competence six months later was abysmal. We rebuilt the training program around role-based learning paths. Instead of teaching everyone everything, we taught each role only what they needed to do their job. A procurement specialist in Vietnam needed different training than a procurement specialist in Sweden, even though they both used the same module. The localized training materials reduced time-to-proficiency from approximately three months to about five weeks.
Phase Six: Cutover Planning
Cutover is the weekend where you shut down the old system and start using the new one. For a multinational with operations in six time zones, this is exponentially more complex than a single-site implementation. The cutover plan we developed covered every hour for a 72-hour window. It included decision gates where project leadership had to determine whether to proceed or rollback. It included communication protocols for notifying stakeholders in real time. It included rollback procedures documented in case something went wrong. During our actual cutover, we encountered a critical issue with tax configuration in the Australian region. The local tax rules had changed six months earlier and our configuration was based on outdated documentation. We spent approximately fourteen hours resolving the issue before we could proceed with Australian transactions.
The rollback plan was never invoked, but having it ready changed the team's behavior. They made faster decisions under pressure because they knew exactly what the fallback option would be. That knowledge alone probably prevented several mistakes.
What Nobody Tells You About Post-Go-Live
After go-live, performance typically degrades for six to eight weeks. This is normal and expected. Transaction volumes spike as everyone tries to use the system simultaneously. Support tickets pile up. Morale drops. Senior leadership starts wondering if they made the right decision. The response team structure we used involved three tiers. Tier one handled basic questions through a standardized knowledge base. Tier two handled configuration issues and process questions. Tier three handled technical problems and data issues. Having clear escalation paths prevented the common problem where every issue gets routed to the same three people, who become bottlenecks that slow everything down.
Hypercare, the intensive support period immediately following go-live, typically lasts four to eight weeks depending on implementation complexity. During hypercare, the project team operates at full capacity with extended hours. This is unsustainable long-term, which is why transitioning to steady-state support needs to begin within the first two weeks of hypercare.
Common Pitfalls That Will Wreck Your Project
Scope creep is the most common killer of enterprise implementations. Every stakeholder will identify additional requirements during the project. Most of these requirements are not actually necessary. Some are necessary but should have been identified during discovery. We implemented a strict change control process where any scope addition required written justification from a steering committee member and impact analysis covering schedule, budget, and quality. This alone prevented approximately 30 percent of the scope requests from being approved. The remaining 70 percent that were approved were genuinely necessary and properly resourced. Another common pitfall is insufficient executive sponsorship. Enterprise implementations require decisions that only C-level executives can make. When sponsorship is weak, decisions get delayed. When decisions get delayed, the project slips. When the project slips, costs increase. When costs increase, stakeholders question the investment. When stakeholders question the investment, funding gets reduced. This is a well-documented death spiral.
The countermeasure is ensuring executive sponsors are personally invested in the outcome. Not nominally invested, but personally invested. This means they attend weekly steering committee meetings, they make decisions within 24 hours when escalation reaches them, and they publicly communicate the importance of the project to their organizations.
The Realistic Timeline and Budget
A multinational enterprise implementation typically requires 18 to 36 months depending on organizational complexity, number of countries, and degree of customization required. The budget usually ranges from 2 million to 50 million euros, with most mid-to-large implementations falling between 8 million and 20 million. The cost breakdown is approximately 35 percent consulting services, 25 percent internal resources, 20 percent software and licensing, 12 percent infrastructure, and 8 percent contingency. The contingency line is important. It is almost always exhausted, and usually insufficient. If your initial budget estimate comes in below 5 million euros for a multinational implementation spanning more than five countries, you should reconsider the estimate, not the scope.
When Enterprise Implementation Is the Wrong Choice
Enterprise implementations are not universally appropriate. They fail completely for organizations with fewer than 500 employees, companies undergoing active restructuring or merger activity, and organizations in industries with rapidly changing regulatory environments where the system will need fundamental reconfiguration within two years of implementation. In those cases, modular cloud solutions or incremental upgrades may provide better ROI. The temptation to implement a full enterprise suite is strong, but it is often the wrong solution for organizations that haven't outgrown their current systems significantly enough to justify the investment. The companies that succeed with enterprise implementations are those that recognize the scale of the effort, prepare for the difficulty, and maintain realistic expectations about outcomes. The technology is the easy part. The people and processes are where the actual work happens.
