Data Migrations Source to Target - Not always a direct hit.

At times the effort to migrate data is thought of as one of those unnecessary evils, just something that needs to be closed out; that mindset is ready, fire, aim. While this may get your project kicked off quicker, you are creating a high impact / high probability risk to your project’s timelines, and quality efforts.

Here are just some of the questions you should be asking, which in turn will help develop your charter, requirements, and any needed RFI / RFPs.

  • What is the level of complexity for this migration, for example?

    • Is this a single source of data or are there multiple sources that need to be moved to the target?

      • One migration effort I worked on we took two Argus safety databases and migrated them into one instance with another provider. This required additional coordination efforts to ensure that they were both mapped and migrated within a single timeline.

    • Are there any plans for a managed service component post migration?

      • This will add further levels of complexity

  •   What is the amount of data needed to be transferred, this question can help determine things, such as?

    • Media to use for transfer

      • sFTP 

      • external media.

    • Transfer count checks from source to targeted staging area.

  •  What is the quality of the source data and are there any data cleansing needs before beginning the extract?

  • What about other quality factors during the execution phase?

    • Quality control checkpoints.

    • Testing and acceptance criteria.

  •   Are there any critical dependencies that need to be met?

    • Does the migration need to be completed before another system or product can be launched?                          

Some key aspects for vendor consideration are:

  • What is your current relationship with the vendor?

    • For a current client, after a POC (proof of concept) where we detailed our selection criteria for an eTMF SaaS partner, and after working with them on the redevelopment of their TMF migration SOPs, plans and SOW’s, we now drive our outcomes based on SOW agreements and drafted migration plans.

  • Based on your assessment of the level of complexity, what experience does the vendor have doing these types of migrations?

  • What about meeting any of your dependency needs, what is their track record for meeting agreed upon timelines?

  •   Do they have the critical procedures in place providing needed validation points you require and/or from a regulatory standpoint?

By considering the above, as well as additional content needed, you’ll be able to minimize your risk factors, help ensure your data quality and functional post migration capabilities; you’ll be aiming first, before firing.

Want to discuss how to align all the above elements and others, which are too numerous to discuss in a short blog, let’s connect?

Next planned blog – But I don’t want to be a project manager. – Key areas of focus when asked to manage a project, when it’s not your day job.

Previous
Previous

But I don’t want to be a project manager – Running a project when it’s not your day job.

Next
Next

Identifying your key requirements during the RFI / RFP process for a CTMS - Don’t forget the big picture.