When people think about cloud migration, they usually think first about applications. They have an on-premise application, such as an enterprise resource planning system, and they want to replace it with a SaaS application that performs a similar function. Once the cloud application is running, the project is complete.
But from our experience at Slalom guiding organizations through cloud migration projects, we’ve learned that it often makes more sense to think first about migrating data rather than applications. In most cases, we turn to the question of application and data services only when we have figured out why and how we’re migrating data to the cloud in the first place.
Data is the most important asset of nearly every company today — it’s the “new oil” of this digital economy. You might want to move data to the cloud so it can be used by a variety of cloud applications and data services, not just the on-premise application that is using it now.
But you’ll likely overlook all the new use cases for your data in the cloud if your migration project is limited to replacing on-premise applications with their cloud equivalents.
When you focus instead on data, you end up thinking more broadly and creatively. Focusing on data also helps lay the groundwork for data management in the cloud, which is key to successfully modernizing and transforming your digital business.
For now, let’s get started by considering seven best practices for migrating data to the cloud.
1. Think through what you really want to achieve
To begin with, identify the outcome you want to achieve by migrating your data to the cloud. Is it better performance? Improved scalability? The opportunity to take advantage of new technologies available only through cloud services?
If you’re not sure what new technologies are available in the cloud, you might want to explore that topic beforehand. Do some research, looking into how you can make the most of the data your organization already has or that it routinely collects.
“When you focus on data, you end up thinking more broadly and creatively.”
Document the goals driving your migration. It’s fine if your plan includes some sweeping, long-term initiatives. But be sure it also includes some short-term goals that are readily achievable, so your project can demonstrate value and build momentum along the way.
If you set a sweeping goal, such as replicating a thirty-year-old on-premise infrastructure in the cloud within a year, you’re probably going to be disappointed. Set a goal that’s important but achievable and can serve as a first step for additional migration work in the future.
The cloud offers tons of benefits, but don’t underestimate the due diligence needed to ensure a successful migration project.
2. Don’t assume that your cloud architecture should replicate your on-premise architecture
Don’t assume that you should simply “lift and shift” when moving to the cloud. For example, if you’re running a data warehouse on-premise in Oracle now, and you’re interested in taking advantage of the cost/performance benefits of the cloud, don’t assume that you should simply move your data to Amazon Redshift (the data warehouse service available through Amazon Web Services).
To fully leverage the cloud, it might be best to combine the data warehouse with other data services. Determine what business result you’re really trying to achieve, and work with an enterprise architect to design the cloud services that will deliver that result. Migrate to the architecture that’s going to meet your needs going forward. It might end up being a mix of applications and services, even if your on-premise implementation consists of a single application.
3. Work with a cross-disciplinary team from the start
As you’re planning your migration to the cloud, be sure you’re talking to more than the data scientists, application developers and cloud architects. Include your security and networking teams, to ensure that the migration to the cloud makes sense for your organization’s broader data management needs.
Also include leaders from business units who might be affected by the migration. You certainly want to have some members of the executive team on board to champion the project.
Recognize that there might be competing priorities. Try to get buy-in early on.
4. Determine if your data would benefit from a multi-cloud strategy
In most data migration projects, a company moves data to applications and storage hosted by a single public cloud service, such as Amazon Web Services (AWS), Google Cloud Platform or Microsoft Azure. But sometimes it makes sense to move data to services spread across multiple vendors. This is what’s known as a multi-cloud strategy.
If your data is going to benefit from a multi-cloud strategy, it’s good to figure that out up front and plan accordingly.
Why adopt a multi-cloud strategy for data? There could be several reasons:
- Unique services: A cloud vendor might offer a special application or service that’s worth using, even if other applications or services are better handled by another vendor.
- Better price/performance: Even if it’s not unique, an application or service offered by one vendor might be so much more affordable or deliver so much better performance that it’s worth adopting, while other applications and services are handled by another vendor.
- Industry experience: Some vendors are very familiar with the exacting requirements of a special industry or market. For example, Microsoft has a strong record with cloud offerings that meet government requirements for data privacy and data security. If a vendor has expertise in an area relevant to your organization, you might trust certain data and applications to that vendor, while choosing another vendor for less specialized services.
- Compliance: If the data you’re migrating to the cloud is subject to the EU General Data Protection Regulation (GDPR) or other regulations that call for data localization (the storage of data within a particular nation or region), then you might want to set up a cloud architecture with independent instances in multiple regions. You might end up working with one vendor for Europe, another for North America, and so on.
5. Identify and clean up data discrepancies before you migrate
Before you migrate data to the cloud, you want to make sure it’s accurate and complete. You also want to make sure that it’s consistent.
When we work with clients, we often run into the problem of “shoehorning.” Shoehorning data means using a single data field to hold different types of data. For example, a CRM record might have a field that has no governance behind it, so one user enters phone numbers in it while another uses it for street addresses and another uses it for last names. This typically occurs when there’s only one unlocked field for data, so each user enters whatever data is most important to them.
But if we’re going to move that data to the cloud, we want to clean up this inconsistency. Phone numbers belong in phone number fields, last names in last name fields, and so on. And some of that data might fall under data privacy rules and regulations, so we definitely want to know where that data is and how it’s being stored.
Before migrating data to the cloud, audit the data, identify any inconsistencies and resolve them before you migrate that data to the cloud and perpetuate the problem there.
“A low-code iPaaS lets you quickly take care of your “throw-away” code, and gets your IT talent back to focusing on the more strategic projects that are going to pay off over the long term.”
6. Look for a platform that will minimize the amount of “throw away” work you have to do
With any substantial data migration project, there’s going to be some amount of coding that’s going to end up being “throw-away code.” You might need software to perform a one-time-never-to-be-repeated transformation, or you might need to move data to a temporary system or location before completing the migration. Especially in large enterprises with lots of legacy systems, the need for some amount of “one-off” coding is inevitable.
But just because throw-away code is a necessity doesn’t mean that you want to invest a lot of time in it. You want to write just enough of it to get the one-time job done, and then move on.
One of the advantages of a low-code platform for integration and migration — an integration platform as a service (iPaaS) — is that producing one-off integrations and transformations becomes quick and easy. If you need to extend integrations or transformations with custom Java code, for example, you can.
A low-code iPaaS lets you quickly take care of your “throw-away” code, and gets your IT talent back to focusing on the more strategic projects that are going to pay off over the long term.
If you need to create temporary code, you can create it quickly and easily. When that code is needed, its usefulness might be great, but when that time is past, the loss is minimal, because you haven’t had to invest a lot of time and effort in something that turned out to be temporary. Simply put, low-code equates to low overhead and low-loss.
7. Use a modern iPaaS to take advantage of both integration and data management
Some companies are wary of the idea of data management, because they assume that, done properly, data management requires a multi-million dollar investment and five years to implement. But modern technologies such as the Boomi iPaaS make it possible to establish a golden record and carry out ongoing data governance far more efficiently.
One reason a unified approach to integration saves time and money is that both your integration processes and data management system are sitting on the same platform in the cloud. This eliminates the need to send data from one cloud application down to an on-premise data management system and then back up to another cloud application.
A unified platform like Boomi’s can keep everything in the cloud, directly connecting one application to another. It creates a cloud-based hub-and-spoke structure among your various applications.
With cloud-based data governance, there is no need to download drivers or set up a complex on-premise data management system. You can get things going quickly and easily in the cloud, which is where you’ve migrated your data.
Second, because the iPaaS is managing the integrations, you can build data management and data cleansing right into your integration process, so data moving from one application to another is accurate and complete.
Third, because of the low-code development interface, you can implement your data governance policies quickly and effectively. You don’t have to embark on that multi-year, multi-million dollar project — instead, you can start seeing benefits in months or even weeks.
Quick, Effective, Forward-Looking Migration
We’re living in a golden era for analytics, as companies realize the power of big data and artificial intelligence for transforming operations and delivering better business results. Those analytics and operations depend on data, so it makes sense to focus strategies on data first and on applications second.
By following the best practices I’ve recommended here, you’ll be able to migrate data to the cloud more quickly and effectively. And you’ll be ready to take advantage of the wealth of cloud applications and services emerging by the day.