All too often, when a heavily-regulated company (e.g. in Life Sciences) puts out a Request for Proposal (RFP) for data migration in line with a major system update, there is a significant mismatch between the work they specify and what will actually be needed to do the job properly.

That’s because moving data across to the new system, and ensuring it’s clean, compliant and optimized to deliver everything that the new software enables, is far from straightforward. It is a major undertaking in its own right, and needs complete buy-in and active partnership from the client side.

The following three tips will help enormously in planning next migrations:

1. Be realistic in your project scoping.

Once Procurement teams and their respective KPIs become involved in the purchasing process (after initial discussions of the project plan and the need for a Class I Project Manager), talk typically moves swiftly to cost and the use of offshore resources.

Yet, this massively undervalues the importance of the data and its integral role in the success of the overall system project. To get the most out of the new system, any imported data will need to be checked, cleaned and enriched so that it delivers as needed, and is fully compliant and can be relied upon to support new operating models – such as IDMP-based Regulatory exchanges, in the case of Life Sciences.

We would always recommend a ‘Best Shore’ approach to data migration, combining the right skills sets and knowledge to do the job as effectively as possible – for instance, with a Class I Project Manager and other strategic capabilities more locally, drawing on other resources on an off-shore basis to fulfil delivery. (We have service locations across the US, Europe, and India.)

2. Understand your role in the engagement – even if you want the external partner to assume the bulk of the work.

It is one thing deciding on the right software for a major system replacement or update, but when it comes to preparing the data to be migrated to it there are all sorts of considerations that need careful thought and communication, which will need the active involvement of the client. This is not about throwing a project over the wall and letting someone else get on with it.

Ideally, for every role that is assigned to an external expert, there needs to be a counterpart internally – from a Project Manager, to business people who can make the time to attend workshops and collaborate with the external service provider on what’s important, who will perform what roles (e.g. enrich the data to ensure its future compliance).

Our experts at fme can take care of every aspect of a migration project – from business consulting and data enrichment, to migration and any system integrations. BUT, this needs to be scoped and resourced appropriately as part of the project plan to keep control of costs and timelines, and ultimately to ensure that the new system project doesn’t fail.

Trying to set a fixed price for a project without first agreeing the parameters is a bit like trying to build an Airfix model without the instructions – a recipe for disaster.

3. Agree effective timelines, based on both priorities and contingencies.

Again, this comes back to the need to be realistic and pragmatic from the outset. This requires total transparency between client and migration partner, and a collaborative approach to the project from the outset.

So, for example, if the reasons behind tight deadlines are to do with a need to be out of a data center by a given date, or are linked to targets and bonuses, it’s important that all parties understand this and can work with those priorities. Often a staged approach to migration can work best, and this can be adapted so that the right elements are scheduled first. Staging can also allow for the reality of team members taking time off for vacations.

Thinking back to projects that have gone off the rails with other vendors can be really useful in all of this. As long as you view your migration/full-service partner as a strategic and integral part of your team, you can’t go far wrong. Speaking for fme, we can bring talent density, knowledge and experience right across the project spectrum – spanning business consulting, technology services, and managed services – as long as all of this has been factored in from the start.

So, let’s start talking.

For more information, please complete this contact form and we’ll schedule a time to discuss your specific requirements.

When planning a digital transformation with a complex data migration, it’s essential to define the key steps from ideation to execution. Today, we will run through the essential steps for a successful data migration.

When it comes to the migration of data in the life science industry, we are generally dealing with a comprehensive set of sensitive data. This could relate to drug product or medical device registrations, IDMP data, or pharmacovigilance data. Unfortunately, life-sciences companies often underestimate the scope of work involved in a successful data migration. Even when they are convinced that their data is in a good shape, they often discover during the process that the data needs to be enhanced, mapped, or revised. Simply put, they underestimate the effort required for the migration activities in comparison to the implementation of new business applications. After all, a business application is only viable when the data are aligned with the required business processes. For this reason, the migration of data should be treated with the same care as the implementation of the solution itself – clear definition of project scope, strategic planning, detailed monitoring of progress, and a formal quality assurance approach. Each of these components are essential to the complete migration strategy.

Understand the migration scope

Developing a firm understanding of the migration scope is pivotal in terms of setting realistic expectations around timelines and outcomes. Consider a specific scenario in which a company needs to migrate thousands of product registrations from a legacy system to the new system, with the assumption that out-of-the-box custom features will be implemented as well. The business needs to determine which registrations are in the migration scope, and whether there are any products that are retired and outside the migration requirements. Additionally, it must be confirmed if the drug products are for human use or also medical device registrations, and what kind of submission format is involved. Other considerations would include any expectations around the enrichment and the migration of IDMP data, as well as the source of the master data. These are just some of the questions that might arise during the assessment phase and must be clarified.

Furthermore, the business must confirm which entities of data will need to migrate. In the example above, it should be considered how to map registration with the target entities, how the data fits into the master data, and what are the expectations of migrating product registration. Other considerations would be whether to migrate the latest registration status or to build the full history with the appropriate status, and how to migrate variation records that are no longer subject to regulatory inspection.

Scoping of migration should always consider the business requirements to get the project’s whole picture and understand how the source data will be used. It’s important to go through the assessment phase, set the scope at such a detailed level that can be understandable and recognized by all stakeholders, and have the same expectations when delivering the project. The assessment should be carried out by an expert that understands the business processes, knows the migration process and the expectation of the target system.

 Create an integrated plan

After the migration scope is known, a plan of action must be established that follows the migration strategy within the larger digital transformation initiative. It is important to involve all stakeholders in the planning phase and understand the activities of the implementation of the new or upgraded information system. Migration activities should go hand in hand with implementation activities, but the migration project should have its own capability to measure progress separately.

When you need to migrate large amounts of data, you will need to put them in different buckets that should go along with the solution implementation cycles. In most cases, some dependencies give you the order of the migration. For example, migration of the master data can be a separate bucket as they are a dependency of the product registration data migrating. Buckets of data can already be defined in the assessment phase, and this is an important input for the planning phase as well as the data location and quality. The plan should consider all potential downtime and there should be agreement between all stakeholders as to what is the optimal time for data transfer activities. Develop a backup plan for identified risks and make an action plan in case of migration activity failure.

 Validate the migration rules with your experts

Another critical step is defining the migration and testing rules and acceptance criteria. It is advisable to organize workshops with business stakeholders to review, refine and confirm the migration rules proposed by the migration team. At this stage it’s important that the team members also define all essential use cases to prevent data errors in migrated data in the target system.

Ensure the implementation consultant is fully briefed on the migration rules associated with the source data. They can warn you about the gaps, especially if the target solution is not out-of-the-box and some custom fields and features were added. Break the data into a logical subset and build out one category at a time, followed by a dry run using the real data from the migration team in the sandbox environment. This is also the step where the business conducts the mapping and provides any data the target system requires but is missing in the source system. The result of each cycle is the validation of the migration rules, migration scripts for data transition and test scripts.

 Validate the migration

Data migration validation is a very important step as the migration team and the business need to ensure data compliance and have a workable solution. Testing done during the build phase is not sufficient and should be carried out on real data, using the test scripts after the migration is completed. The testing strategy defined at the beginning will provide a framework for validation activities along with resource and time allocations. If the testing approach and scope are not set early enough, it might lead to higher costs, longer timelines and could delay compliance validation and approval. It is advisable to include a test specialist in the building phase to understand the business requirements and the transformation/migration specification. The migration leads should help them understand all the use cases to test, and by engaging with business stakeholders on each cycle, can define the user acceptance testing approach.

 The final migration

After approved validation, the final migration can proceed to the production environment. The migration strategy dictates how the migration will be performed, in one go or incrementally, and how to shut down and dispose of old legacy systems. All stakeholders should agree on when to freeze the legacy system, the downtime of the target system, and communicate how to proceed with the migration of data. Once the migration is complete, a final validation should be executed to prove that the migration was performed in accordance with the validation phase.

Conclusion

Before initiating the project, it is crucial to understand the migration scope, what needs to be migrated, whether the source is one system or several systems, what the data looks like, whether or not data enhancement is expected, what are the business requirements, what is the amount of data (e.g., registrations) and establish a migration plan based on these facts to avoid any surprises later in the project. A critical phase of the project is migration validation, as a lack of quality data in the target system can harm business decisions.

fme has been guiding global pharmaceutical and manufacturing firms through their complex migration journeys for over 20 years. We’ve even developed our own proprietary tool migration-center to enable seamless migrations with minimal downtime. Contact us to discuss your challenges and start your journey on the right path.

Additional Migration Resources

fme continually publishes articles from our experts about migration topics. Review some of them below, and then contact us to discuss your current challenges.

• Overcoming Data Migration Challenges: 3 Essential Steps for Success
• Migration strategy and the path to operational resilience
• Smoothing the road to RIM transformation with Veeva
• Case Study: Journey to a Single Harmonized Regulatory Content Source Management Solution
• Case Study: Migrating Content from Legacy OpenText Documentum to Veeva QualityDocs
• fme Migration Services Assessment: Get started right