Vecture

Know what you are migrating before you estimate it

Migration estimates are usually built on counts: files, jobs, reports, terabytes. Those numbers describe the size of an estate. They say little about how hard it is to migrate. Our assessment analyses the estate itself, so that scope, sequence and effort rest on evidence.

Why object counts mislead

Two estates with the same number of jobs or reports can differ by a factor of several in migration effort. What drives the difference is rarely visible in an inventory:

  • dependencies: how many components rely on the same shared datasets
  • reuse: logic copied across projects that should become one component
  • procedural logic that does not translate to set-based processing
  • external and manual inputs, such as spreadsheets someone uploads every month
  • fan-out: a single table feeding hundreds of reports
  • rules that exist only in code, or only in someone’s head
  • reports that are near-duplicates of each other
  • constructs the target platform does not support

A list of ten thousand objects tells you how big the estate is. A dependency graph starts to tell you how to migrate it.

What the assessment analyses

Estate inventory

What actually exists, extracted from the systems themselves: projects, programs, packages, mappings, procedures, reports, universes, schedules and the tables they touch. Our Source Harvesters do this read-only.

Dependency graph

What depends on what, at table level and at column level where the sources allow. The graph distinguishes static dependencies found in code and definitions from runtime dependencies observed in execution logs, because the two are not always the same. It highlights shared components with high fan-in or fan-out, tightly coupled clusters, dead assets, and dependencies that are ambiguous and need a person to confirm them.

Transformation complexity

Which logic is simple, which is repetitive and can follow a common target pattern, which is procedural, which uses unsupported constructs, and which is ambiguous.

Consumption layer

Which semantic models, reports, extracts and downstream systems depend on the outputs being migrated. A change that is harmless at table level can still break a measure or a report, so this belongs in scope from the start.

Operational behaviour

Where execution history is available: schedules, frequencies, run times, failure and retry patterns. These determine the orchestration design and the cutover plan.

Migration candidates

What can be translated largely automatically, what needs to be redesigned, and what can be retired. Legacy Data Miner supports the scoping decisions with usage evidence.

Migration waves

Which workloads can move independently and which must move together, in an order that respects the dependency graph and delivers usable results early.

Validation strategy

How equivalence will be demonstrated for each tier of output, and where a parallel run is justified. See how to prove a migration is correct.

What you receive

  • Migration inventory of the estate, extracted rather than self-reported
  • Dependency map, with shared components and coupled clusters identified
  • Complexity classification of every workload
  • Migration wave proposal with sequencing rationale
  • Exception and ambiguity register: what automation could not resolve and who needs to decide
  • Target pattern recommendations for Microsoft Fabric or Databricks, including the platform choice where it is still open
  • Validation strategy by risk tier
  • Migration backlog ready for delivery planning
  • Effort and risk ranges, with the assumptions behind them stated

Estimates are given as ranges with explicit assumptions. A single precise number at this stage would be false precision.

The purpose of an assessment is not a nicer inventory. It is to reduce uncertainty before engineering capacity is committed.

How it works in practice

An assessment takes from one week to one month, depending on the size of the estate. We need read-only access to the legacy platforms, or exports of project files, repositories and metadata where direct access is not possible, and a small number of conversations with the people who run and use the estate. Nothing in the legacy environment is changed. A non-disclosure agreement is signed before anything is shared.

  1. Access or exports
  2. Automated extraction
  3. Dependency graph
  4. Complexity and usage analysis
  5. Review with your team
  6. Waves, backlog and ranges

The deliverables belong to you and are usable by any delivery team, including your own or another partner.

Legacy platforms we assess

Planning a migration, or stuck in one?

Send a few lines about your estate. We reply within one working day, and sign an NDA first if you need one.

info@vecture.be