A list of migration challenges tells you what might go wrong. A risk register records what the programme is doing about it, who is accountable and what evidence will show whether the risk is under control.
That distinction matters. “Hidden dependencies” is a concern. “An undocumented reporting application may continue querying the legacy warehouse after cutover, causing inconsistent business reporting” is a risk that can be investigated, assigned, monitored and acted on.
A useful Databricks migration risk register connects each material risk to its cause, evidence, likelihood, business impact, preventive controls, detection criteria, contingency and owner.
It starts during discovery, but it stays active until the target is stable and the legacy platform can be retired.
What is a Databricks migration risk register?
A Databricks migration risk register is a living record of uncertain events that could prevent the migration from meeting its scope, correctness, security, service, cost or decommissioning objectives. It is both a management tool and a decision record.
| Question | Risk-register field |
|---|---|
| What could happen? | Risk event and consequence |
| Why could it happen here? | Cause and current evidence |
| How serious is the exposure? | Likelihood and impact |
| What reduces the chance of it happening? | Preventive control |
| How will we know it is materializing? | Indicator, trigger or control evidence |
| What will we do if it happens? | Mitigation or contingency |
| Who is answerable for keeping it controlled? | Risk owner |
| When must the decision be revisited? | Review date, phase gate or escalation threshold |
Government project-delivery guidance makes an important ownership distinction: each risk should have a named owner with the authority or expertise to manage it, even when other people perform the response work.
A programme lead can own a cutover risk while an SRE prepares the rollback steps and application owners run consumer tests. The work is distributed; accountability is not. See the UK Government’s Teal Book risk-management guidance.
Risk register vs migration challenges, discovery and checklists
These artifacts overlap in subject matter because they describe the same programme. They should still produce different decisions.
| Content or artifact | Main question | Expected output |
|---|---|---|
| Migration risk register | What could derail this migration, who owns the exposure and how is it controlled? | Rated risks, controls, triggers, contingencies, owners and decisions |
| Common implementation challenges | What problems commonly occur across Databricks implementations? | Failure patterns and broad responses |
| Discovery | What must be understood before scope approval? | Evidence, assumptions, scope, constraints and initial risks |
| Migration roadmap | What will happen, in what order? | Phases, waves, dependencies and milestones |
| Implementation checklist | Have the required activities been covered? | Completed, open or not-applicable actions |
| Migration timeline estimate | What determines the calendar duration? | Planning range, assumptions and critical path |
A risk entry is not a task in disguise. “Run reconciliation” belongs in a plan or checklist. The corresponding risk is that source and target results may differ beyond the agreed tolerance, with reconciliation acting as a control and a failed comparison acting as a trigger.
How to score migration risks without false precision
For most programmes, Low, Medium and High are sufficient at the start. Define the terms locally:
- Likelihood: How plausible is the event in this migration, based on evidence rather than intuition?
- Impact: If it occurs, how seriously would it affect business correctness, security, service, regulatory obligations, cost, schedule or the ability to retire the source?
- Inherent risk: Exposure before the planned controls are working.
- Residual risk: Exposure after those controls are implemented and evidenced.
The simple likelihood-by-impact model is a prioritization device, not a mathematical forecast. A “High/High” label should cause a decision: reduce exposure, change the migration approach, secure a fallback, accept the residual risk through a named authority or stop the affected wave.
The ratings below are illustrative starting points for a substantial enterprise migration. Replace them with your organisation’s definitions and evidence. A well-documented, low-criticality batch estate may rate very differently from a regulated platform supporting intraday decisions.
The register should also include status, target treatment date, next review date, residual rating and approval authority when moved into a working tool.
Risk management should support decisions throughout delivery, not become a reporting exercise; that principle is consistent with the UK Government’s Orange Book.
Databricks migration risk register
This is a baseline, not a universal catalogue. Delete entries that do not apply, split risks that have different owners and add source-specific exposure discovered during assessment.
Databricks’ current migration tooling can provide evidence for several entries. Lakebridge separates assessment, SQL conversion and source-to-target reconciliation.
Its Profiler examines live workload patterns, while Analyzer reviews exported code and reports complexity and interdependencies. Those outputs can reduce uncertainty, but they do not replace application knowledge, business acceptance or programme ownership.
Scope, dependencies, people and conversion
| ID | Migration risk | Typical cause or evidence | L | I | Preventive control | Detection or trigger | Contingency | Primary owner |
|---|---|---|---|---|---|---|---|---|
| R01 | An undocumented workload or consumer is omitted and fails after cutover | Inventory built from interviews only; shared credentials; unexplained source queries; missing lineage; ad hoc extracts | H | H | Combine catalogue, scheduler, repository, access-log and query-history evidence; interview source and consumer owners; map end-to-end dependencies | Legacy queries continue during parallel run; consumer smoke test fails; an owner disputes the inventory | Hold the affected cutover; maintain a controlled legacy feed or routing path; add the consumer and its validation to the wave | Migration Lead; supported by source-system and BI/application owners |
| R02 | Scope expands after commitment and invalidates the delivery baseline | “Like for like” is undefined; modernization requests enter migration waves; no change authority; dormant assets reappear | M | H | Define in-scope workloads and finish conditions; separate mandatory compatibility work from optional modernization; establish change control | Workload count, acceptance evidence or target-pattern decisions change beyond the agreed threshold | Rebaseline the wave, defer lower-value assets or approve added capacity and budget explicitly | Programme Lead; Executive Sponsor approves material changes |
| R03 | Source or business SMEs are unavailable when decisions and UAT are needed | Named people have no reserved capacity; knowledge sits with one contractor; month-end conflicts with test dates | M | H | Confirm named deputies and availability by wave; schedule business-cycle tests; record decision deadlines | Questions age past the agreed limit; UAT sessions are missed; acceptance evidence remains unsigned | Resequence unaffected workloads; escalate through the Business Product Owner; delay acceptance rather than assume behaviour | Business Product Owner; Programme Lead supports escalation |
| R04 | Stored procedures, UDFs or proprietary ETL require more redesign than planned | Analyzer flags unsupported or very-high-complexity constructs; dynamic SQL; side effects; temporary objects; proprietary components | H | H | Analyze representative code before estimating; prove the target pattern in a pilot; classify convert, refactor, retire or replace | Conversion errors rise; generated code needs repeated manual changes; unit behaviour differs | Move the workload to a specialist rewrite track, narrow the wave or retain it temporarily on the source | Data Engineering Lead; supported by Platform Architect and source SME |
| R05 | Converted code runs but produces different business semantics | Implicit casts, null behaviour, collation, time-zone handling, rounding or undocumented business rules differ | M | H | Define business-level invariants and golden datasets; review high-risk logic with domain owners; test edge cases, not only syntax | KPI, aggregate or exception-set differences exceed tolerance despite successful execution | Stop promotion; trace the first divergent transformation; correct or redesign the logic and rerun downstream validation | Business Product Owner for acceptance; Data Engineering Lead for remediation |
| R06 | Migrated workloads miss performance or SLA requirements | Source baseline absent; different execution model; data skew; concurrency not tested; Python UDFs or poor target design | M | H | Capture source runtime and concurrency; define non-functional acceptance criteria; test production-like volumes and schedules | Runtime, queueing, freshness or concurrency crosses the agreed threshold | Tune or redesign; increase capacity temporarily; stagger cutover; keep the source workload active until the SLA is demonstrated | Databricks Platform Architect; workload owner supports acceptance |
Lakebridge can accelerate mechanical conversion, but support varies by source and transpiler. Its current tool-selection documentation marks the LLM-powered Switch transpiler as experimental and says generated notebooks may need manual adjustment.
Treat “transpiled” and “accepted” as different states. A syntax-valid result is evidence that code can run; it is not proof that the same business decision will come out.
Data, orchestration, governance and platform readiness
| ID | Migration risk | Typical cause or evidence | L | I | Preventive control | Detection or trigger | Contingency | Primary owner |
|---|---|---|---|---|---|---|---|---|
| R07 | Historical data is incomplete or materially altered | Unclear retention boundary; schema/type mismatch; precision changes; failed partitions; duplicate or missing keys | M | H | Agree history scope and field mappings; validate schema, counts, keys, nulls, aggregates and high-value records; preserve load audit evidence | Reconciliation fails; partitions or periods are absent; business totals exceed tolerance | Reload the affected slice from an immutable source copy; quarantine target outputs; extend validation | Data Engineering Lead; Data Owner signs off tolerances |
| R08 | Source and target diverge while both remain active | Source changes during bulk load; CDC lag; inconsistent watermark; late-arriving data; final-sync procedure unproven | M | H | Define source-of-record rules, catch-up logic and an auditable cut-off; rehearse final synchronization under realistic write volume | CDC lag breaches threshold; watermarks disagree; new source records appear after freeze without target matches | Pause cutover, replay from a known checkpoint, extend dual operation or re-run the final synchronization | Data Engineering Lead; Source-system Owner controls source changes |
| R09 | Jobs or downstream integrations break because migration order is wrong | Incomplete DAG; hard-coded endpoints; cross-platform workflow; external API, file or scheduler dependency not represented | H | H | Build dependency graph; group complete production workloads into waves; test cross-platform interfaces and repointing | Upstream completion does not trigger downstream work; target job reads stale source output; consumer connection failures | Restore prior routing for the affected chain; move the full dependency set into one wave; run a controlled bridge temporarily | Migration Lead; application and orchestration owners support |
| R10 | Target privileges do not preserve required business access boundaries | Role hierarchy not mapped; ownership unresolved; workspace-local permissions assumed; negative access tests absent | M | H | Design the Unity Catalog model before workload promotion; map identities, groups, privileges and ownership; test allowed and denied paths | Required user loses access; unauthorized principal succeeds; grants differ between environments | Block promotion of affected data; revoke broad temporary grants; restore approved access path while remediating the model | Data Governance Lead; Security Owner approves sensitive access |
| R11 | Sensitive data is exposed through temporary migration paths or excessive permissions | Broad staging credentials; unmanaged copies; engineers granted standing admin access; exports outside governed storage | M | H | Minimize and time-bound privileges; govern staging locations; encrypt transfers; log access; define deletion and evidence requirements | Unexpected access event; stale staging data; broad grant persists past expiry; security test fails | Isolate the data path, revoke credentials, invoke the incident process and repeat the migration through an approved pattern | Security / Cloud Platform Owner; Data Governance Lead supports |
| R12 | Production environments are not ready when workloads arrive | Networking, private connectivity, identity integration, cloud permissions or quotas remain unresolved; manual configuration drift | M | H | Establish a production platform readiness gate; provision repeatably; validate connectivity, identities, policies, observability and capacity before wave entry | Deployment or connectivity test fails; dev and prod differ; service principal lacks access; required quota is unavailable | Repoint the wave to the approved environment only; defer promotion; use a pre-approved temporary capacity option where safe | Databricks Platform Architect; Cloud Platform Owner supports |
Databricks’ production-planning guidance treats security requirements, network planning and identity-provider information as explicit inputs to production design.
If another team owns those inputs, the migration register should capture the dependency, decision date and escalation path rather than assuming the platform will be ready.
For governance migrations, Databricks’ current Hive Metastore to Unity Catalog guidance recommends assessing compatibility in the context of the current architecture and minimizing disruption during cutover.
That supports an evidence-led control approach; it does not justify assuming that existing grants or ownership will translate automatically.
Acceptance, cutover, coexistence and decommissioning
| ID | Migration risk | Typical cause or evidence | L | I | Preventive control | Detection or trigger | Contingency | Primary owner |
|---|---|---|---|---|---|---|---|---|
| R13 | Validation cannot demonstrate that the workload is acceptable | No tolerances or golden results; syntax tests substitute for semantic tests; UAT owner absent; month-end not exercised | H | H | Agree acceptance criteria before build; combine technical reconciliation, business scenarios, security tests and non-functional tests | Tests pass mechanically but sign-off is withheld; exceptions cannot be classified; critical cycle remains untested | Keep the workload out of production; add missing scenarios and owner; extend parallel validation through the relevant cycle | Test / QA Lead; Business Product Owner owns business acceptance |
| R14 | Cutover fails because the window or consumer-switch sequence is inadequate | Runbook unmeasured; final sync competes with other work; downstream teams switch at different times; communications unclear | M | H | Rehearse the runbook; time each step; define command centre, checkpoints, freeze, communications and consumer order | Gate misses its time box; final sync or smoke test fails; mixed source/target traffic appears | Stop at the defined checkpoint; revert routing for affected consumers; invoke an extended window only through named approval | Migration Lead; Operations/SRE and application owners execute |
| R15 | Rollback is required but cannot restore a consistent service | “Rollback” is only a document; target has accepted writes; reverse synchronization is undefined; source capacity or credentials removed | M | H | Define what can actually be reversed; test restore/routing steps; set data-write and decision cut-offs; preserve source capability for the agreed soak period | Restore rehearsal fails; recovery time exceeds window; target-only writes cannot be reconciled | Do not cut over until an approved alternative exists; use forward-fix or workload isolation only if explicitly accepted | Migration Lead; Operations/SRE owns technical procedure; Sponsor accepts residual risk |
| R16 | Parallel run lasts indefinitely or produces conflicting results | No exit criteria; dual changes are not synchronized; users keep both systems; exceptions are never dispositioned | M | M | Define system of record, change policy, comparison scope, exit criteria and maximum review point before parallel run | Legacy usage stays flat; configurations drift; unresolved differences accumulate; duplicate operating cost exceeds threshold | Freeze nonessential changes, choose authoritative outputs, narrow coexistence or escalate a new cutover decision | Programme Lead; Business Product Owner resolves output authority |
| R17 | The legacy platform cannot be decommissioned after cutover | Late dependency; archive or regulatory evidence incomplete; contract notice missed; no one owns shutdown approval | H | M | Treat decommissioning as part of scope; inventory residual access; agree archive, evidence, licence and approval requirements early | Queries continue after cutover; archive test fails; sign-off or contract action remains open | Keep a reduced, access-controlled source footprint; pause compute where feasible; create a dated closure plan with explicit cost owner | Source-system Owner; Executive Sponsor approves retirement |
| R18 | Migration throughput and budget assumptions prove invalid across later waves | Pilot selected only easy workloads; defect and remediation effort not measured; shared SMEs or environments constrain parallel teams | M | H | Select a representative pilot; measure conversion, validation, defect and waiting effort; maintain assumptions by workload class | Actual throughput misses planning band; residual risk or defect rate rises by wave; shared dependency becomes critical path | Reforecast remaining waves, change sequencing, reduce scope or add capacity where the constraint can genuinely be parallelized | Programme Lead; Engineering Leads supply evidence; Sponsor approves rebaseline |
Lakebridge Reconcile currently supports schema, row-hash and joined data comparisons for specified source systems. That is useful control evidence, not the whole acceptance case.
Databricks’ broader data-migration guidance also separates data reconciliation, application testing, performance validation and user acceptance. The register should therefore state which form of equivalence matters for each workload.
Ownership: assign the risk to the person who can make the decision
The risk owner is accountable for keeping exposure within the agreed tolerance. A control owner or action owner performs specific work.
For example:
- The Data Engineering Lead may build reconciliation tests.
- The Business Product Owner owns the risk that migrated financial outputs are not fit for use, because that role can define tolerance and withhold acceptance.
- The Migration Lead owns cutover coordination.
- Operations/SRE owns the executable rollback procedure.
- The Executive Sponsor accepts material residual business risk when it cannot be reduced before a deadline.
Avoid assigning every technical-looking entry to “Databricks Engineering.” An engineer cannot resolve missing business acceptance, compel a network team to deliver private connectivity or authorize legacy-system retirement.
Dateonic’s guide to roles for Databricks implementation provides the broader team context; the register should name one accountable person for each actual risk.
Which risks deserve early escalation?
A risk does not need the highest score to require programme attention. Escalate early when one or more of these conditions apply:
- the consequence affects correctness, confidentiality, regulatory evidence or business continuity;
- the control depends on a team outside the migration lead’s authority;
- no credible fallback exists;
- the uncertainty is still high close to a decision gate;
- the same exposure affects several waves or a shared platform component;
- the response needs budget, scope or policy authority the owner does not hold;
- the detection point would occur only after users or downstream systems switch.
This is why a missing network approval and an unverified accounting rule can both be programme-critical, even though only one is a platform issue.
How the register changes during the migration
Discovery establishes the first evidence base. It does not finish the risk-management work.
| Migration point | What should change in the register |
|---|---|
| Before scope approval | Record major unknowns, assumptions, source access, external dependencies, platform-fit questions and decision owners. Do not lower risk because discovery work is merely planned. |
| Before a pilot or migration wave | Replace estate-level guesses with workload-specific evidence. Confirm dependencies, business criticality, target pattern, acceptance owner and contingency. |
| During conversion and build | Update ratings from actual unsupported constructs, semantic defects, performance results and integration findings. Create separate entries when causes or owners diverge. |
| Before UAT or parallel run | Shift attention from conversion progress to correctness, business-cycle coverage, stakeholder availability, operational behaviour and exception handling. |
| Before cutover | Review only current evidence. Confirm final synchronization, consumer switching, security tests, rollback feasibility, open blockers and acceptance authority. |
| After cutover | Track service stability, late consumers, data drift, access issues and the conditions required to end the rollback window. |
| Before decommissioning | Require evidence that residual queries, archive obligations, licences, recovery needs and business approvals have been closed or formally accepted. |
Pilot evidence should recalibrate later waves. Databricks’ migration decision framework advocates assessing workloads individually and migrating incrementally.
That same logic applies to risk: a pilot is valuable when it tests representative complexity and changes the controls or assumptions for what follows.
Use the register for cutover go/no-go decisions
Not every open risk must be eliminated before cutover. Some residual risk can be accepted when the remaining exposure is understood, monitored and within the organization’s tolerance.
The cutover decision should distinguish:
- Blocker: the agreed condition is not met, so the affected workload does not switch.
- Tolerable open risk: the control is operating, the remaining exposure is within tolerance and a named authority accepts it.
- Exception with action: cutover may proceed, but a time-bound action, owner and trigger remain active.
- Unknown: evidence is insufficient. Treating an unknown as a low risk is not acceptance.
Examples of organization-defined blockers include:
- reconciliation outside the agreed tolerance;
- unresolved access-control failures involving sensitive data;
- a critical downstream dependency that has not been tested;
- missing business acceptance for the workload;
- no viable restore, rollback or forward-recovery strategy where one is required;
- failure to meet a regulatory or operational evidence requirement.
Agree these criteria, the decision deadline and the approval authority before the cutover call. Otherwise, the meeting becomes a negotiation under time pressure.
Rollback also needs an honest definition. Databricks’ 2026 Synapse migration guidance advises against decommissioning the source too early and notes that preserving it can retain a fallback while the target proves itself.
That does not make every migration reversible. Once the target accepts unique writes or downstream systems act on target results, returning to the source may require reconciliation or forward recovery rather than a simple switch back.
Example: an undocumented consumer from discovery to closure
Consider a legacy table that appears to feed three Power BI reports. The source team believes nothing else uses it, but query history shows a shared service account reading the table overnight.
| Stage | Register update |
|---|---|
| Initial entry | Risk: an unknown downstream consumer may remain on the legacy table after cutover and produce stale or inconsistent outputs. Evidence: unexplained nightly queries through a shared account. Inherent rating: High likelihood / High impact until the consumer is identified. |
| Ownership | The Migration Lead owns the risk because it affects wave scope and cutover. The BI Owner and Source-system Owner perform the investigation. |
| Preventive control | Review query text, network logs, scheduler metadata and credential usage; trace the service account to an application; add the consumer, connection change and acceptance test to the dependency map. |
| Trigger | During parallel run, any unexplained production query to the legacy table or a failed consumer smoke test blocks closure. |
| Contingency | Do not switch off the table. Keep a controlled legacy feed while the application is repointed and validated. Record the extra coexistence cost and a decision date. |
| Residual assessment | Once the application owner is identified, target connectivity is tested and no unexplained legacy access appears for the agreed observation period, reduce the rating according to local scoring. |
| Closure evidence | Named application-owner sign-off, successful target smoke test, updated connection inventory, no relevant legacy queries during the agreed window and decommission approval. |
Notice what closes the risk: evidence that the consumer has moved, not the completion of an investigation task.
Before you approve the migration plan
Review the register alongside the scope and wave plan. For every High-impact entry, ask:
- Is the risk statement specific enough to describe cause, event and consequence?
- Is the rating based on current migration evidence?
- Does the preventive control reduce likelihood, or merely describe what happens after failure?
- Is there a measurable trigger or control result?
- Is the contingency technically and operationally possible?
- Does one named owner have the authority to act or escalate?
- Is the residual risk acceptable to the person authorizing the wave?
- What evidence will close the risk rather than simply mark an action complete?
If those answers are missing, the programme has a list of concerns, not a functioning risk register.
How Dateonic can help
Dateonic helps teams turn migration uncertainty into a delivery plan grounded in actual workloads and dependencies.
That can include source-estate assessment, target Databricks architecture, workload and code analysis, governance design, validation planning, migration-wave delivery and cutover preparation.
The objective is not to promise a zero-risk migration. It is to expose material risk early, assign it to someone who can act and build enough control evidence for informed scope, wave and cutover decisions.
Discuss your Databricks migration with Dateonic.
For source-specific considerations, see Dateonic’s Snowflake to Databricks migration guide and Hadoop to Databricks migration guide.