This document outlines the processes and methods that Hopp Tech follows, to ensure that data migration projects we deliver are successfully implemented.
These are based on the methods laid out in Practical Data Migration, the only industry-standard migration framework, which defines four Golden Rules for data migration:
- Data Migration is a business not a technical issue. Although a data migration requires technical solutions for it to be delivered, the data being migrated is owned by the business.
- The business knows best. This follows from rule 1. Not only does the business best understand its own data, but it also has knowledge of the “unofficial” data stores, such as spreadsheets, etc., that are secretly used to manage parts of the business.
- No organisation needs, wants or will pay for perfect quality data. Perfect data quality may seem to be a good aspiration, but all projects have limited resources. A successful project can only improve data quality within the limits of these resources.
- If you can’t count it, it doesn’t count. To address any data issue, you must be able to identify the records affected.
The delivery of this methodology is supported by the Hopp migration software, which has gained PDM Compliance certification.
For a deeper look at how this methodology fits into delivery, see Overview : Hopp Support.
Hopp Tech's Approach to Data Migration
At Hopp Tech, we focus on one thing: complex data migrations. Our approach has been shaped by years of experience delivering projects where data quality, traceability, and business validation are critical.
We specialize in staged, transparent migrations that never compromise on control.
We structure our migrations across three core phases: preparation, delivery, and sign-off. Each is supported by a robust framework of tools, governance, and methods all purpose-built for enterprise-scale migrations.
Preparation: Setting the Foundation
Before any data is moved, we ensure the right structures are in place.
We start with a Data Migration Strategy, an executive-level document that outlines the scope, responsibilities, project interfaces, technical and policy requirements, and how the migration fits into the wider transformation program.
This strategy is built from outputs developed during discovery and planning and sets the direction for all subsequent activities.
This phase also includes the development of Migration Sign-off Requirements in collaboration with Data Owners.
These define what needs to be true for migrated data to be considered acceptable and what evidence is needed to prove it. This is further detailed in Migration Sign-off: Introduction : Hopp Support.
Critically, we also establish the Data Task Group, a cross-functional team of data owners, business experts, and system leads who oversee issue management and own the decisions on what gets prioritized.
Managing Migration Issues: A Dedicated Process
Unlike other delivery risks or IT incidents, data migration issues require their own governance.
That's why Hopp Tech maintains a separate Migration Issues Log, powered by our proprietary Item Manager tool.
This log captures every data-related issue from discovery through to resolution, with full traceability.
Issues typically originate from two places: discovery (for example, through Landscape Analysis), or from sign-off criteria that can’t yet be met.
As implementation progresses, the volume of issues tends to grow rapidly and handling them becomes central to migration success.
Every issue is evaluated by the Data Task Group and assigned both a technical priority (how severely it affects the migration) and a business priority (how critical it is to operations).
The higher of the two determines its overall status.
For example, data that won’t load at all would be “Critical” technically, whereas data that loads fine but breaks a key business process might still be “Critical” from a business perspective.
For a further breakdown of how this works, see Issue Management: Introduction : Hopp Support.
Issues are then allocated to Releases, where they’re tracked and resolved. We also distinguish between three types of issues:
- Discovery Issues, usually identified early, often during Landscape Analysis.
- Standard Issues, which arise during mapping and testing and are handled in Releases.
- Monitoring Issues, where data has been fixed but still requires oversight to ensure the problem doesn’t recur.
Hopp Tech offers a full Migration Issues Process Guide for customers, and the Hopp Portal supports detailed reporting, monitoring, and weekly updates from legacy systems to track fix progress.
Delivery: Structured, Iterative, Transparent
We deliver data migrations using a blended Agile approach, coordinated within the wider waterfall-style program. Each major test migration is broken down into smaller Releases, typically two weeks long.
These Releases function like Agile sprints, each culminating in a full load of the migration staging database.
A week before each Release begins, we host a Release Planning Meeting, chaired by the Hopp Lead Migration Analyst and involving the Data Task Group.
Here, we agree on what will be delivered, including which Business Objects are involved, the extraction rules, and which migration issues will be addressed.
The outcome is a formal Release Note. Early in the Release, a follow-up meeting confirms details or reissues the plan if needed.
Each Release involves mapping, transformation, test loading, and review, and each contributes to building towards a full milestone migration, which is typically the only opportunity for users to see their own data in the new system before go-live.
Ideally, all major mapping is complete before the penultimate milestone migration, allowing the final one to focus on “snagging” which is final refinements ahead of the live migration.
Fixing Migration Issues
We use five standard methods for resolving migration issues:
- Ignore: Some issues (like inconsistent phone numbers) may be accepted as-is if they’re not business-critical.
- Fix in flight: Data is corrected as part of the migration process itself, often through automated transformations.
- Fix in source: Legacy systems are updated directly, though this depends on available resources.
- Fix in target: Data is migrated as-is and corrected in the new system post-migration, typically under a controlled transitional process.
- Fall out in flight: The rarest approach, where invalid data is excluded from migration and handled manually afterwards.
All fixes are tracked in the Hopp Portal, with automated support for monitoring and auditability.
Testing: Making Quality Visible
Every Release and milestone migration is tested thoroughly, typically across three levels:
- User Acceptance Testing (UAT) focuses on ensuring migrated data supports functional business processes.
- Reconciliation Testing ensures that data volumes match across systems, and that defined metrics are met.
- Record-Level Testing allows for granular review of individual records and supports full data lineage analysis.
All defects identified through testing feed directly into the Migration Issues Log for resolution in future Releases.
Migration Sign-off: Delivering Confidence
Final sign-off is a structured process involving three key meetings with each Data Owner:
- An initial discussion during planning to define the criteria for acceptance.
- A meeting early in implementation to agree on the exact evidence required for sign-off.
- A final sign-off meeting near the end of the project, once all evidence has been delivered and verified.
These meetings are formally documented, ensuring a clear and auditable approval trail. All sign-off requirements must be considered during Release Planning, so that the appropriate data and reporting are delivered in time to meet go-live criteria.