Daelight Solutions team members have been performing content and data migrations for over a quarter century. What new things could we learn from doing another one?
As it turns out, quite a bit.
Daelight recently assisted a large consumer healthcare company with its transition from Oracle Argus Safety to Veeva Vault Safety, a cloud-based platform designed to streamline and manage the collection, processing and reporting of adverse events and pharmacovigilance data. Let’s explore six lessons we learned, or were reminded of, when performing this large and complex multi-year migration project.
Migrating to Veeva Vault Safety: 6 Things We Discovered
1. Pay Attention to Data Model Changes in Each Release
Dealing with Veeva’s three yearly releases is nothing new when performing Vault migrations. Checking the release notes with a particular focus on data model changes is a given.
However, performing this impact analysis with each release was even more important for this project given its duration (roughly 19 months, during which we absorbed 4 general releases and many more limited and maintenance releases, as well as customer-specific sprints). This was coupled with the fact that Veeva was making several significant product changes given the solution’s maturity.
Be sure to bake enough time in to perform impact assessments for each release and changes that it may cause to migration mapping documentation and/or tool configuration.
2. Ensure Your Vaults Have Identical Configurations
Safety systems have always been complex systems requiring complex configurations. While Veeva has removed some of the complexity as they streamlined the processes and resulting configurations, Safety is still notoriously complicated. Given the number of data points and configurations that can impact migration, make sure your Sandbox, Test and Production Vaults have equivalent, or ideally identical, configurations.
Using the Vault Comparison Tool or Daelight Comparison Tool, along with Vault Snapshots, can help run multiple migrations with a specific set of configurations.
3. Focus on Integrations That Require Migrated Data
External solutions like Signaling and Reporting will always require safety data. It’s essential to provide those teams with access to migrated data, which allows them to test and potentially request changes to mapping rules or enriched data.
The overall testing effort across the program should be harmonized to ensure that all critical functions are tested for both new and migrated data as early as possible. The program plan should ensure that migrated data is available for Vault Safety testing and downstream testing for workstreams like Signaling, DataMart and Reporting.
Issues found in downstream systems can lead to updated migration or data augmentation requirements. It’s important to keep changes like this off the critical path. Testing early with migrated data will help.
4. Account for All Product & Study Registrations
Product and Study Data mapping and migration can be complex, especially for legacy data. Don’t underestimate the importance of planning and resourcing this effort.
Close collaboration with Veeva will also be necessary to ensure that products and studies are configured correctly. Some organizations may rely upon a system of record, such as Vault RIM, for product data. If this is done, it’s important to ensure that all product registrations in the Safety source system, including inactive registrations, are accounted for.
5. Case Attachment and Narrative Management
Understanding how the data and documents stored in the source system will translate to Vault Safety is critical to success. When migrating from Oracle Argus, documents and narratives are two specific things to note.
Specifically, documents in Argus are simply attachments stored as large object (LOB) data in the database or stored in an external system. Not all contain associated data (similar to the Vault concept of Attachments). However, in Vault Safety, every document requires a specific set of metadata based on associated lifecycles and workflows.
During migration, if the documents are stored in a database, they must be converted into an actual file and imported in the correct format. Additionally, in the case of Narratives, a blank Word document must be imported even if the case has no narrative.
6. Close Collaboration with Veeva
Given that most customer Production Vaults run in shared point of deliveries (PODs), it’s essential that a migration process, or any process, does not overwhelm system resources. This challenge is amplified for Vault Safety migrations, given the high number of objects and documents that would need to be migrated for larger customers.
Coordinating the migrating timeline and approach with the Veeva Professional Services and Network Operations teams will help avoid unpleasant surprises during the migration execution.
Conclusion
The lessons we learned from this Veeva Vault Safety migration serve as a roadmap for ensuring smooth, efficient and successful transitions. With careful planning and execution, your migration to Veeva Vault Safety can be a seamless journey toward enhanced safety data management.
Daelight Solutions continues to evolve its migration approach, ensuring that each project leverages our extensive experience while embracing new learnings. Contact us to discuss your migration needs and see how we can help.