Library · Data Practice OS
Migration assessment
Reference guide · Published · Source reviewed
The answer: spend the first four to eight weeks measuring, not converting. The assessment produces an inventory of what exists, evidence of what is actually used, and a Migration pattern per workload. In most legacy data estates 30-50% of objects are unused and can be retired, so the assessment pays for itself in avoided conversion.
What to inventory
| Object | Capture |
|---|---|
| Sources | System, owner, technology, volume, change rate, CDC capability |
| Tables and files | Size, row counts, last write, last read, Data classification |
| Transformations | Stored procedures, ETL jobs, scripts, schedules, runtimes, failure rates |
| Consumers | Reports, extracts, APIs, downstream systems, named users, frequency |
| Dependencies | Job-to-table and table-to-report Lineage |
| Embedded logic | Where Business rules live (procs, ETL expressions, COBOL, report formulas) |
Use free tooling first
- SnowConvert AI assessment reports object counts, conversion readiness and effort. Sources include Teradata, Oracle, SQL Server, Sybase IQ, Redshift, Azure Synapse, Spark SQL, Databricks SQL, BigQuery, PostgreSQL, Vertica, Hive and IBM DB2. It also covers ETL migration for SSIS and Informatica PowerCenter.
- Lakebridge Analyzer profiles legacy SQL, ETL and orchestration, including SSIS, DataStage, Talend, Ab Initio, ADF, Oozie, Teradata, Oracle, SQL Server, Netezza and DB2. It does not list Informatica, so assess Informatica estates with SnowConvert AI or by hand.
Run both, even before the platform choice is final. The outputs feed Choosing a platform - Snowflake, Databricks, or both with real numbers, and neither commits you. Supported sources change, so check the current lists in the SnowConvert docs and the Lakebridge supported sources matrix.
Notes by source type
- CA Gen / DB2 mainframe. Logic sits in generated COBOL and action blocks, not SQL. Neither converter will handle it directly. Plan for rule extraction and a rebuild of the data logic, with Change data capture from DB2 for data. Treat the operational system as a source that stays put, not a migration target.
- SQL Server / Oracle EDW with SSIS or Informatica. The sweet spot for automated conversion. Expect 70-90% of SQL to convert automatically. Procedural code, dynamic SQL and ETL expressions are where the effort goes.
- Hadoop lake (Hive, Spark, Impala). Spark code moves to Databricks with modest change. HiveQL converts to either platform. Formats (Parquet, ORC) can often be registered as Apache Iceberg or Delta tables rather than copied.
Choosing the treatment
| Treatment | When | Typical share |
|---|---|---|
| Retire | No reads in 12 months, duplicate, or superseded | 30-50% |
| Rehost | Rarely used, low value, must keep. Land it as-is in bronze for access | 5-15% |
| Replatform | Sound logic, convert SQL with tools, keep the design | 30-50% |
| Refactor | High value, poor design. Convert, then remodel into dbt Data products | 10-25% |
| Rebuild | Logic not in SQL (mainframe, opaque ETL), or design is the problem | case by case |
Score each workload on value (consumers, decisions supported, AI potential) and effort (complexity, convertibility, data quality). High-value, low-effort workloads form wave one. That is how a Strangler fig migration ships value early.
Usage evidence beats opinion
Pull query logs, report server execution logs and ETL run history for 12 months. "Everyone uses that report" often turns out to mean one person, monthly. Present retirement candidates to owners with the evidence, and give a time-boxed objection window.
Worked example
Suppose the legacy source is a SQL Server EDW with 2,400 tables, 900 stored procedures, 350 SSIS packages and 600 reports. Twelve months of logs show 1,100 tables and 260 reports unread. Both converters assess the remainder: 82% of procedures convert automatically, and SSIS packages split into 60% simple loads (replaced by managed ingestion) and 40% with embedded logic. Registrations and licensing marts score high value and medium effort and become wave one. The output is a wave plan with effort in person-weeks per wave, not a single big-bang estimate.
Pitfalls
- Converting before retiring. Every unused object converted is wasted effort and future debt.
- Ignoring report logic. Calculations hidden in report formulas are business rules too.
- Assessing code only. Data quality problems surface during Reconciliation. Profile key tables during assessment.
- One treatment for everything. "Lift and shift all of it" carries Technical debt into the new platform at cloud prices.
Related: Modernisation and migration, Code conversion, Reconciliation, parallel run and cutover.
Lessons from platform options papers
Source: a platform team's draft options papers and platform docs (Oct-Nov 2026). All draft or proposed. None is an agreed decision; treat them as evidence, not standards.
- Record classification counts per source before planning loads. The platform team's DB2 source-system context (draft, not checked by an SME) counts 689 design tables, 59 of them SENSITIVE and 14 PROTECTED. Do not load PROTECTED data into the platform before information security approves it.
- Compare the deployed schema with the design metadata (for CA Gen, the GEN encyclopaedia) before trusting either.
- Tag every context fact Known, Inferred or Not known, and name the SME who confirmed it.
- Use a new-source workflow. Triage first, checking that the data is not already on the platform. Add two preflight questions: what is the source's classification gate, and what is its tier (Data product tier)?