Migrating an ERP system to the cloud is a significant event with high stakes for the business and the team leading the implementation. Companies invest substantial time and money into both the new systems as well as the migration process. And they’re often eager to get to the other side and reap the benefits that the cloud can offer.

But the question is: How can you get there as painlessly as possible?

I’ve been working on Oracle ERP implementations for two decades. I was part of some of the earliest cloud migrations. I’ve since helped lead multiple cloud ERP implementations, converted large systems, and guided large manufacturing and supply chain operations into the next generation of ERP software.

Along the way, I’ve learned a lot about what makes for a great cloud ERP implementation—and what causes things to go wrong. The secret to a seamless migration is a commitment to preparation and doing the homework in advance so that your organization is more than ready for the move.

Here are three tips that companies considering a cloud ERP implementation should consider:

1. Before you focus on the new system, assess your legacy system. 

Transitioning from an on-premise to cloud-based ERP is a big project with a lot of moving parts. It’s easy to focus most of your attention on the new system, transition, and required changes. However, before you can get there, it is critical to assess your legacy system. You want a solid understanding of how everything works now, including critical processes, customizations, and the cleanliness of your data. It’s also essential to do an honest evaluation of the processes your teams rely on, assessing which are truly valuable and which are perhaps outdated or just habits. For example, many organizations still maintain processes that they used with an older, legacy system that’s no longer around.

A systems assessment ensures you start on the right foot, providing foundational information that your implementation team can use to build out the next-generation solution. Conversely, neglecting this step can cause big problems down the road. Months into implementation, you may discover that you’re building out a customization that’s not needed, or you may miss a critical process that needs to be included and extends your timeline.

2. Be exceptionally diligent about your data. 

In my experience, data is often a problem. And regardless of what system you’re implementing, issues with data don’t go away once you’ve migrated. As you prepare for an ERP implementation, make sure that you understand the details of your data, such as whether master data needs to be inactivated, transactions need to be closed, the volume of your data, and its completeness. Before an implementation project, you want to be sure you can articulate precisely what systems you’re converting data from, especially if there are multiple systems involved. Ask:

• Where does the data come from?
• Do you still use/need all your master data records and their associated elements and attributes?
• Are you retaining data from legacy systems that are no longer of value?
• What data elements will be required for future reporting and new KPIs?

One thing to remember is that you will likely be changing business processes when you move to the cloud. Old processes and workflows that used to be a requirement may not serve you anymore—and some of the data that fueled them may not play a role in your new system. It’s worth your time to determine what data is valuable to your new cloud applications and how the data interacts differently with the cloud. If you are coming from a non-Oracle legacy system, you may even want to bring in a consulting company to assist you with this effort so they can recommend critical data elements in the new application.

3. Practice, practice, practice.

So fast forward to go-live cutover. You’ve configured the system, tested the system thoroughly, and built solid integrations and future state processes. You’re ready to go right? Not yet.

Did you complete a true mock cutover? If so, how many? Don’t forget as you are readying to convert your system to the cloud, prioritize practicing the conversion. There are multiple layers of constraints in the cloud that most organizations haven’t encountered with their on-prem ERP.

For example, in a cloud-based ERP from Oracle, you’re reliant on Oracle to purge data so that you can have a clean conversion environment (in your lower environments), and that may take longer than you think. This is something that needs to be built into your implementation environment strategy ahead of time. You may also need to purge data multiple times to effectively run through mock conversions, which is why planning out your conversion runs with the Oracle dependency is critical. Once you are ready to cutover to production, there is also no guarantee that the ‘timing’ you hit in your lower environment will match in production either. There are always unknowns in a SaaS environment (servers, scheduled jobs, databases) that you do not have control over.

One factor that catches companies off guard is accounting for the volume of records that they’re converting and how that affects conversion timing; how each run (even if the volumes do not change) can take different amounts of time to convert. It often takes longer than assumed. Your cutover timing can also vary at go live (in your production environment) no matter how many times you’ve tested it before because, in a SaaS environment, you will very likely have differences when you do cutover. There are testing conversions, layering in master data, and then transactional data. Also, think about what transactional data can be converted at the same time as other transactional data. How to make up time if you hit a snag in your production cutover can only be truly learned from practicing this very scenario multiple times in preparation. You’ll learn how much the servers and enterprise scheduler can handle, what you should expect regarding peak performance versus the average, and what may cause your system to run slower.

For example, factors like the number of jobs running in the scheduler, the number of users in the system, and the amount of data processed affect your performance slightly differently in a SaaS environment compared to on-premise. It’s also important to create monitoring SRs (service requests) with Oracle ahead of time, perform performance testing tracking times of all conversions, and review any abnormalities with Oracle ahead of your actual cutover. This is especially true in a go live where you have critical dependencies on your downtime (i.e.: in a distribution or manufacturing environment where your system must be up and running in 48 hours for example and you have a non-moveable blackout period).

The bottom line is that you want to run multiple test conversions to test the data, nail the timing, and identify potential issues.

There are so many good reasons to move to the cloud. Thoroughly prepare for the transition, and you’ll reap the rewards of your migration that much sooner.

Have additional questions about migrations? Connect with us.