What is data migration?

Organizations may perform one or more types of data migration depending upon the business objectives and use case. The common types of data migrations are listed and described below.

Storage migration

A storage migration is the movement of data from one storage device or system to another. These migrations enable organizations to deliver on initiatives like upgrading their storage infrastructure, migrating email archives, consolidating data centers and moving on-premises storage to the cloud.

Database migration

Organizations move from one database platform to another for a variety of reasons that may include upgrading database versions, switching platforms, migrating to the cloud, integrating with multiple data sources, increasing scalability, offloading analytical workloads and lowering their licensing costs. Database migrations encompass the migration of database platforms, data warehouses and data lakes but also include platforms like Microsoft Active Directory, which is a database that contains information on your IT resources.

While performing a database migration, organizations need to focus on reducing the impact on availability and productivity while maintaining a real-time copy of production data. To perform impact-free replication, migrations and upgrades without downtime or data loss, they have to keep source and target databases in sync until testing is complete.

Application migration

An application migration is when an organization moves data to a new computing environment. It typically includes migrating the related database and storage and sometimes the application’s database, files and directory structure may need to be modified to accommodate the new application. Organizations often embark on application migrations of programs like Microsoft Exchange or SharePoint during software upgrades and when moving workloads to the cloud.

Cloud migration

There are several scenarios for moving data and applications in a cloud migration. It could involve migrating databases, email or other applications from an on-premises environment to a private or public cloud, between cloud providers or between tenants in a single cloud provider to support consolidation initiatives, global data residency requirements or mergers and acquisitions.

Business process migration

Business process migration involves upgrades and migrations of the data and applications used to support business processes, rules and workflows in systems like ERP and CRM. These efforts are typically performed to update the systems to reflect changes to the business.

Smart IT organizations keep migration on their radar for a variety of modernization reasons:

• Upgrading software: The nature of software is a constant evolution of repeated cycles of security and feature updates, periodic capability upgrades and sometimes an end of life event. With each iteration, you face decisions about whether, when and how to upgrade. While data migration is not usually involved in updates, it can be a factor in upgrades and certainly in end of life situations. In the latter two cases, there may be an opportunities to upgrade your security capabilities or eliminate the licensing costs associated with features nobody is using, for example by migrating from Oracle Enterprise Edition to Standard Edition.
• Upgrading hardware: Even as your hardware gradually ages and degrades, vendors of hardware (especially storage, network and endpoint technology) roll out improvements and must-have security features.
• Upgrading both: You may have the opportunity to upgrade both hardware and database software as part of an upgrade to your enterprise applications such as Oracle E-Business Suite and SAP.
• Merging and consolidating systems: Data migration plays a key part when organizations need to merge, consolidate or separate infrastructure and systems like Active Directory to increase efficiency, enhance their security posture or to support a merger, acquisition or spin-off.
• Changing platform: Data migration is indicated when changing the server operating system; for example, when moving from Solaris to Linux. And the move to a different architecture, such as Oracle Real Application Cluster (RAC), cloud or virtualized environments, requires that IT provide a copy of current data to a different platform.
• Shifting to cloud computing: Cloud suites like Microsoft 365 offer a buffet of collaboration and communication services for organizations of all sizes. What’s more, they take care of applying frequent updates to the component services, absolving you of the cost and complexity of managing more equipment in your datacenter.
• Keeping up with growth: How quickly could you respond to a merger or acquisition? If you had to integrate your cloud IT environment with that of another enterprise, would you be ready? Your company’s next M&A event may result in tenant-to-tenant migration and consolidation.

In all of those scenarios, your business will look to you not only to execute the upgrade quickly but also to mitigate any risk of data loss or downtime. You can prepare yourself by tuning and testing your new environment before you start moving your users to it.

Here are some key best practices for data migration projects:

• Line up the expertise you’ll need: The expression “get the right people on the bus” definitely applies to data migrations. Make sure your key roles in the project have the right mix of knowledge and experience to ensure a smooth transformation.
• Comprehensive planning: Start your project by analyzing all of your applications and processes, and evaluate the users requiring access to them. It’s important to measure how migration will likely affect your workflows, programs and infrastructure, so be sure that you have sufficient resources when the migration takes place. It’s a mistake to dive into a major migration without first assessing the current environment and needs.
• Ensure user and business continuity: To avoid disrupting productivity, schedule the most resource-intensive tasks in your migration project for times when users will be least affected.
• Plan for coexistence: In all but the smallest data migrations, it will be necessary for to-be-migrated systems and users to work smoothly with already migrated ones. Yet some projects still founder because there has been no provision for coexistence between existing and new systems. Typical consequences are lost productivity, service disruptions and higher overall costs to migrate.
• Thoroughly test the new system: You know how important it is to test your applications thoroughly before making them available to your end user community. But you may face pressure to get systems back online before you’ve properly tested them. That shortens downtime at the expense of increasing the risk of a failed migration. A better approach is to replicate the activity from your production environment to your test environment. After a couple of days of replication to test the new environment, begin running read-only tests and checking your reports and queries to ensure compatibility between old and new environments. Finally, implement in the new environment the features that are most important to you and see whether you can update your applications. That will ensure the smoothest transition.
• Have a robust rollback plan: What if your migration project fails? What is your plan B? Suppose it appears that your new application is working as expected, but you discover that new data is getting lost? You’ll need to enable users to work in the original environment without loss of uptime and data. Unless you had tools in place to capture the entered data, you would risk increased downtime and impact on the business.
• Prevent the loss of data: Extend your backup and recovery plan for the contingency of restoring data quickly and easily if something goes sideways in the middle of the project. This is your most prominent hedge against the risk of data loss during migration.
• Manage the project effectively: It’s imperative to run a data migration project like any other IT project, including scheduling, deadlines, project management and progress reporting. And, once you’ve migrated, keep it up by continuing to optimize your new environment.

Depending on their source, data migration tools fall into a few categories.

Internally scripted tools

If your IT team has the time and expertise, it may create its own custom scripts for the data migration. This approach favors suitability to purpose over the expense of licensing and learning to use a migration tool. But it does require that you spin up a development project on top of your migration project. It also usually causes downtime.

Platform vendor tools

Database vendors provide their own native tools for migration, as in this Oracle migration scenario:

Export and import – You can use Oracle's utilities to move data between machines, databases or schemas. The utilities are not difficult to run, but they are prone to time-consuming errors and they use a file format proprietary to Oracle databases. Moreover, you’ll incur downtime as you export and import the data.

Oracle Data Pump – A step up from a utility, Oracle Data Pump is a server-based tool for moving data and metadata between Oracle databases. Again, downtime is an issue, and the tool does not support XML schemas and XML schema-based tables.

Database upgrade wizard – This wizard allows you to upgrade a standalone database in place. It is limited in the number of instances you can upgrade at a time, and in the database versions it can move.

Oracle transportable tablespaces (XTTS) – XTTS can be faster than an export-import operation, but along with your data it moves all of the fragmentation and sub-optimal objects and tablespace designs.

Third-party tools

Dedicated replication tools offer an approach to database migration without downtime. They are designed so that you can completely replicate databases from source to target, enabling migration or upgrade of production system during normal work hours. When you’ve tested the new environment to your satisfaction, you can switch over to it without downtime, optionally keeping the old and new environments in sync after the switch.

Third-party tools also exist for each stage of Microsoft 365 migrations. Tools for pre-migration planning allow you to discover and assess user and group dependencies, conflicts, and unused accounts, and see who has rights to AD and Azure AD resources. Migration tools move and restructure AD and file server data and let you schedule moves and update permissions for all types of objects while maintaining coexistence and user productivity. Post-migration management tools automate provisioning tasks with full auditing of AD, Exchange and other Microsoft 365 cloud services.