Planning successful migrations to the cloud

July 10, 2023 | 9 minute read
Text Size 100%:

Get more information link

The Fusion Insider Editor's Note: This business brief offers concrete guidance from the Fusion Development Team for organizations in the middle of or planning a move to the cloud, plus customer examples of successful migrations. We hope it will provide an invaluable perspective to help you create your own cloud migration plan. You can also download a PDF version

Purpose

This document offers a perspective on successful migrations and guidance for businesses planning a move to the cloud, whether the business is new to cloud or part-way through the journey and planning their remaining migrations.

Introduction 

Planning a successful move to the cloud is much like planning a sight-seeing trip. For any destination, certain sights will be considered must-sees by most travelers. Yet even with the same target attractions, travelers’ itineraries will differ based on considerations such as where they are starting, their preferred mode of transportation, the climate they favor, and so on. Parallel dynamics are at play when planning a move to the cloud. Successful migrations share certain must-see qualities, but businesses’ ideal implementation plans will vary based on a few key considerations.  

The Basics of Successful Migrations 

Common objectives 

Well-thought-out migrations balance multiple interests, and a business’ best plan will likely be some form of compromise of risk and reward. Successful plans reflect the business’ priorities and take into account the areas which will benefit the business the most by moving to the cloud, whether due to the advantages of a particular cloud solution or the savings from turning off a relatively expensive piece of their existing infrastructure. At the same time, however, a sound plan will balance attempts to maximize benefits with efforts to minimize deployment risk and complexity.     

Big bang vs. phased approach 

Businesses yet to move any operations to the cloud may be tempted to consider a big bang approach, but given the objective of minimizing risk and complexity, a big bang is rarely, if ever, the best answer. Only for the narrowest projects, with the simplest of footprints, might it make sense. In other scenarios, moving everything at once has significant drawbacks, most notably being the risk associated with too many moving parts. Big bang moves require complex coordination and the involvement of people from across the organization for the duration of the project.  

In contrast, dividing the project into smaller pieces simplifies effort and reduces risk, enabling more focused attention and the involvement of fewer people at any one time. Phasing also offers faster time to results, with customers seeing value from the first go live. Finally, initial phases can serve as proof points and businesses can incorporate early learnings into later phases for better overall results.  

In most cases, it is preferable to divide a move to the cloud into manageable pieces or phases

Blueprint for a Phased Implementation 

Just as there is no single best itinerary, there is no single best way to divide a project. A business’ ideal plan will depend upon a few key considerations. The answers will be different, but the questions to consider are the same. 

At any stage of a business’ journey, the questions below will help identify the best way to phase remaining migrations. 

What operations are mission-critical? 

Yes, everything is important. But some things are more important than others. Especially in larger and more complex scenarios, different stakeholders will often have conflicting opinions on what should move where, when, and in what order. In the face of competing pressures, it’s important to have already established which business operations are truly mission critical, prior to planning, so the most essential areas can be prioritized and protected from undue risk. 

How can integrations be minimized? 

Integrations and risk go hand in hand. And integrations come at a cost – both the data cost between systems and the business process cost of orchestrating what goes where. While a phased implementation may require incremental integrations to support the interim phases, businesses should avoid adding complex, bi-directional integrations to the system. Given the overall goal of minimizing integrations, areas that already rely on integration back into the core, are prime candidates for separate moves.  

What are natural separation points for the business? 

Projects can be split across a variety of dimensions. Lines are often drawn by geography, business process, line of business, or some combination of the three. However, what makes sense for one business may not make sense for another. Careful assessment of a business’ current operations and existing footprint will reveal logical separation points. For example: 

  • Does the business have multiple legal entities or distinct business units that operate separately? 

  • Are there lines of business with dissimilar business models (e.g., manufacturing vs. consulting services)? 

  • Are there business processes that rely on unique systems or technologies? 

  • Are there acquired businesses that operate independently? 

  • Does the business operate globally or are different geographies managed independently? 

and so forth…. 

What connections should not be broken? 

Just as there are logical separations, there are illogical ones as well. Certain business operations are too entwined to be reasonable candidates for separation. For example, a business running accounts payable and purchasing would not be advised to implement one without the other, and rarely would a business want to move order management and supply chain functions separately. Splitting such closely knit functions involves complex, back-and-forth integrations that increase project risk and difficulty. 

In Practice 

Collectively, the above considerations can guide a business to its own best implementation plan. While this guidance isn’t entirely prescriptive, it is in no way theoretical or hypothetical. We’ve seen countless customers, across industries, employ the approach successfully to migrate even the largest and most complex on-premises footprints to the cloud. We have included a few customer examples in the appendix. We also noted a recent McKinsey article on this topic, which we believe shows strong parallels to the recommendations shared here.1 

Appendix 

Customer Examples 

In their successful journeys to the cloud, the customers below split their migrations into manageable pieces, drawing division lines along dimensions that best suited their business. In the interest of brevity, the stories are focused on excerpts of the customers’ journeys and are not intended to be comprehensive accounts from beginning to end.  

FedEx 

FedEx Corporation is an American multinational conglomerate providing customers and businesses with transportation, e-commerce, and business services worldwide. They have over 530,000 employees serving over 220 countries and territories globally. 

An acquired business played a key role in FedEx’s migration of ERP and SCM solutions to the cloud. FedEx had acquired a smaller company that was running its business on a different on-premises solution than what FedEx was using. Rather than migrating the acquired business to FedEx’s on-premises solution, they decided to move the acquisition’s operations directly to the cloud, implementing ERP and SCM solutions globally for that line of business. Because it was a smaller line of business, migrating the acquisition gave FedEx a low-cost, low-risk opportunity to explore cloud ERP and to develop a model for the rest of their business. With that successful migration under their belt, they turned their attention to rolling out cloud ERP and SCM to the rest of FedEx’s global operations. They divided this much larger endeavor geographically, beginning with a go-live for about 20 countries across Europe, India, and South America. From there they moved to rollouts across Latin America and Asia Pacific, and finally North America. 

Grupo Bimbo  

Grupo Bimbo, S.A.B. de C.V., is a Mexican multinational bakery product manufacturing company headquartered in Mexico City, Mexico. One of the world’s largest baking companies, Grupo Bimbo has over 13,000 products across 100+ brands, with 214 bakeries and more than 1,600 sales centers strategically located in 34 countries throughout the Americas, Europe, Asia, and Africa.   

Prior to moving to the cloud, Grupo Bimbo had been running different versions of their on-premises solution around the world. Rather than moving them all to the same version, they decided to move them all to the cloud. Given the scope and scale of Bimbo’s operations, this was a massive undertaking. They decided on a multiphase implementation, rolling out the solutions by geography, and phasing in different business processes at different stages. 

Grupo Bimbo started by establishing a global template and rolling out the included ERP and SCM solutions in their newly acquired operations in Morocco first. After deploying in that country, Bimbo began implementation in Peru and Chile and expanded to include HCM applications. They moved next to operations in Mexico and, in the middle of that process, began implementation in Colombia, Paraguay, and Argentina. Along the way, the global template expanded to include advertising and customer experience applications in countries with more complex operations. From there, Grupo Bimbo moved on to implementing ERP, SCM, HCM, and CX in the United States, Canada, Mexico, and China.  

HSBC 

HSBC is one of the world's largest banking and financial services organizations serving 72 countries and territories in Europe, Asia, the Middle East and Africa, North America, and Latin America.  

Embarking on their move to the cloud, HSBC undertook a global replacement of their ERP systems, with a goal of establishing global shared service centers across 300 legal entities. One of the first functional areas to be migrated was ERP Financials. The geographical distribution of their operations offered logical separation points for the move. Rather than dividing the project by business process, HSBC deployed their full financial management solution by geography, beginning with a rollout in the UK. This initial deployment was followed by rollouts in the Asia Pacific region, and then subsequent rollouts to the rest of the world.  

Oracle 

Oracle is a global technology company with 170,000 employees and annual revenue of $42B. It operates in 175 countries, serving 430,000 customers across multiple lines of business including software, hardware, consulting, education, and subscription services. 

Given the breadth and scale of operations, Oracle opted for a phased migration to the cloud. Because Oracle operates globally, across many lines of business, the project was divided almost exclusively by business process.  

Prior to moving to the cloud, Oracle had 32 different country and regional charts of accounts. The move to the cloud was used as an opportunity to establish a global chart of accounts, so the first module Oracle implemented was ERP Accounting Hub. This established a global chart of accounts and isolated the existing subledgers from disruption during the move. Oracle next identified a few solutions that would be high value for them. These were solutions that lent themselves fairly well to running standalone and could provide immediate value, by significantly improving automation and/or by filling a particularly pressing business need. The business implemented these solutions, which for Oracle included HCM Talent Management and CX Configure, Price, Quote, next. After these select implementations, Oracle addressed their core solutions, phasing them to the cloud globally in a few steps, beginning with HCM applications for their large, global employee base. Those were followed by ERP Financials and SCM Supply Chain Planning, then other SCM applications for their hardware business, and finally other back-office applications to manage revenue, receivables, and order management functions. 

Related Content 

McKinsey Digital Article 

1.  Bossert, O., Nocker, F., Schrey, C., & Soganci, M. “The ERP platform play: Cheaper, faster, better.” McKinsey Digital, 9 Feb. 2023, mckinsey.com/capabilities/mckinsey-digital/our-insights/the-erp-platform-play-cheaper-faster-better

Connect with us 

Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at: oracle.com/contact. 

Copyright © 2023, Oracle and/or its affiliates. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. 

​Oracle, Java, MySQL, and NetSuite are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.​ 

If you're an Oracle Partner and want to learn more, visit the Oracle Partner Community.

Get more information link

Related posts you might like

Fusion Development

The Fusion Development team is responsible for building, maintaining, and driving innovation on the Oracle Fusion Cloud Applications Suite, which includes Oracle ERP, EPM, SCM, HCM, and CX. Its members are based throughout the world with central offices in the US, India, Mexico, The Philippines, and Romania.


Previous Post

Easy ERP add-on to automate account reconciliation

Fusion Development | 4 min read

Next Post


New—HR case management for HCM Help Desk available now 

Fusion Development | 5 min read