A business might have several reasons to opt for data migration, for example, merging multiple systems into one central system, or switching to modern platforms as opposed to traditional platforms, to make use of the features and benefits provided by modern platforms. The reasons can be many, but the most important aspect is the approach you follow for data migration and the reasons for choosing it.

The 6Rs framework provides a structured approach to transition data, workflows and processes from an old environment to new environment, and acts as a guide on how to manage the existing systems while you move to the new ones.

How to write data migration requirements?

One of the important tasks to determine what you want to do with your existing systems is to write data migration requirements. This will give a clear picture on how you want the migration to happen, for example, what are systems you can get rid of, what are the systems that you want to merge, what new business rules can you create for the new system and so on.

Here is a quick checklist to write your data migration requirements:

• Data analysis - Suppose you had a system that did not have enough validation checks on the forms submitted by users, leading to a lot of gibberish being entered into the storage systems. Additionally, it is possible that some mandatory information was missed out or data for the same field had different values from various different sources. Such data discrepancies, and missing or bad data needs to be corrected or removed. After cleaning the data, it needs to be analyzed to understand what data is redundant, what fields can be combined, or added before moving to the new system.
• Brainstorming and feedback - Once data analysis is done, all the business stakeholders must come together to finalize the data and systems that need to be migrated, the ones that can be left off or removed, and the ones that need to be overhauled. It is possible that new use cases pop up during the brainstorming sessions.
• Data and business rules mapping - This involves mapping source fields to the target fields as well as updating/adding business rules. It is very important to map the source and target fields, especially if you have large datasets and are changing from one database management system to another, for example, from a traditional SQL database to more modern NoSQL platforms need to match the type availability and retain the relationships between the data. Similarly, you need to create new business rules that cater to the new systems or update the existing rules such that they cover the scenarios for the new systems. For example, if you are merging two departments of a company, say “infra” and “admin”, the business unit field that was earlier infra or admin should now be the same for both - let’s say “IT”.
• Tools and techniques - The next step is to look at the bigger picture - what are the new interfaces required to access your services, do you need to train your team to be able to work on the new system and leverage the full potential of the new systems, what are the tools required for migration of applications, services, data and workflows, who are the potential vendors that serve your purpose and can provide the features in the new system you want to build, and so on. These questions need thorough brainstorming to arrive at a decision on what you are going to do with your existing systems and how you are going to migrate them.

6Rs of migration

The 6Rs determine the approach you are going to follow for your migration. Based on the above data migration requirements, a business can come to a conclusion on: 

• The type of data they need to keep and maintain
• The interfaces and use cases they require (to interact with other applications, and for other applications to interact with them)
• The workflows required for the business to function
• The business rules that need to be followed by the new modern system
• Analytics platform that can help generate more business and identify shortcomings

These 6 important R’s are:

1. Rehost: Just lift and shift (move) applications from one platform to another with minimal downtime or changes
2. Replatform: Lift and shift with tweaks (tinkles) and optimizations to leverage the full benefits of the new platform, but with minimal changes to the application code
3. Repurchase: Replace the existing application with limited features to a ready to use solution with modern capabilities that can be customized to suit your business
4. Refactor: Re-architect the existing solution and break it into multiple microservices to enhance scalability and leveraging the benefits of cloud.
5. Retire: Retire the systems that are no longer required or are rarely used, thus reducing maintenance overhead costs and simplifying the overall application architecture.
6. Retain: Retain the applications that are used by many other systems and cannot be immediately migrated.

Let us understand each step using a simple example.

Imagine an e-commerce company ABC that has multiple complex systems and wants to perform data migration.

Replatform

Scenario1: As the company is growing and its customer base is increasing, ABC is unable to expand its capabilities because of the highly customized platform they built long back. ABC is unable to take advantage of newer, more efficient technologies available in modern platforms, for example, better disaster recovery and high availability features.

To solve this problem, the application can be replatformed, i.e. move to a modern cloud platform while making optimizations to enhance scalability and extensibility. This will also ensure you avoid a complete redesign of the application.

Rearchitect

Scenario2: As ABC’s business grows, managing and keeping track of details like inventory, employee details, purchase orders etc, are either outdated, or have grown to the extent that it is difficult to retrieve or maintain. Further, the relationship between various types of data has become complex to maintain too. ABC definitely needs cleanup, transformation and organization of data.

In the above scenario, there are three major problems that need to be addressed:

• Volume and complexity of data
• Outdated systems that are hard to maintain
• Need for data cleanup and transformation

A possible way to address these problems will be to Re-architect the systems, i.e. redesign applications to use the modern technologies and storage systems that can handle the complex nature of data. In future, as the complexity grows, the data platform should be able to absorb and maintain the complex relationships between data with ease. Further, using cloud technologies could help solve the problems of scalability and maintainability.

Repurchase

Scenario3: ABC also felt a need for a platform to easily add new use cases and business rules, to cater to existing royalty customers and attract new customers. The system should automatically update new launches, offers, and promotions based on demand and other factors, and also suggest related products and services to customers.

Well, this is not exactly a problem, but a value add that can greatly enhance user experience and increase sales. To address this, ABC can adopt a SaaS solution (repurchase) that provides these capabilities out-of-the-box, eliminating the need for extensive in-house development and maintenance. They only need to train their employees to use and manage the SaaS platform.

Rehost

Scenario4: ABC’s product catalog, Employee Information System, CRM, and data analytics platforms are tightly integrated and currently hosted on-premises. These work fine, but require better performance and scalability.

When the world is moving towards the cloud, even the perfectly working applications should, for a better future outcome. ABC should rehost (lift and shift) these applications by migrating them to a cloud environment. This shift will enhance scalability and reduce maintenance overhead without touching the existing architecture.

Retain

Scenario5: ABC has a customized complex payment system that handles all financial operations. The system has all the regulatory requirements formulated and tested over the years, and integrated with several other systems that use this system. While this system works perfectly well, migrating and changing it would mean risking the integrity of the system and requires thorough analysis and testing.

ABC needs to retain the existing system and focus on regular maintenance and monitoring to ensure continued compliance and performance, and perform thorough analysis of the risks and processes involved, if the need for migration arises.

Retire

Scenario6: Recently, ABC realized that a few of its categories of products and the workflows related to it, are no longer required. These need not be carried over once the migration is done.

As these pieces of code are obsolete and no longer required, ABC should retire them for good.

Summary

The 6R framework is a comprehensive model to guide users through the migration process and provides an understanding on which approach they should follow based on different scenarios they encounter during the migration process. Note that the above scenarios are just examples and do not cover every situation that a business may encounter during migration. Hope the article provides a good understanding of the 6Rs of data migration.