Your estate, written down
Behavior, control flow and run semantics for every asset: reconstructed from the native definition, not the labels.
The knowledge base: your legacy estate, finally documented.
One shared, versioned store where every Documenter writes down what your legacy assets actually do: behavior, lineage, risk and migration status. The Librarian curates it; every other agent reads from it; your team can browse it. It is the memory the whole migration runs on, and it's yours to keep.
What it is
One source of truth the whole fleet shares.
Traditional migrations scatter knowledge across spreadsheets, tickets and the heads of a few experts. The fleet does the opposite: every Documenter reconstructs the functional behavior of a legacy asset and writes it as a structured entry into a single, versioned knowledge base. Nothing downstream guesses: the Architect, the builders, the Test agents and the Operators all read from the same place.
- Documenters write structured functional specs, not screenshots
- The Librarian deduplicates, cross-links and versions every entry
- Every downstream agent reads from it; humans browse it
- It's target-agnostic: document once, decide the platform later
# kb/assets/dwh_load_dimcustomer.yaml asset: DWH_Load_DimCustomer source: tool: ssis package: DimCustomer.dtsx documented_by: ssis-documenter behavior: pattern: scd_type_2 control_flow: - { task: TRN Staging, type: execute_sql } - { task: DFT Load, type: data_flow, components: 7 } - { task: UPS Dimension, type: execute_sql } run_semantics: incremental, watermark ModifiedDate lineage: [SRC_CRM.Customer, STG.Customer, DWH.DimCustomer] risk: score: 0.62 drivers: [script_task, dynamic_sql] targets: fabric-dbt: models/marts/dim_customer.sql status: stage: test iteration: 3 last_fix: "row-count delta in SCD backfill, patched by fabric-dbt-builder" gates: assessment: approved design: approved promotion: pending
The side effect you didn't pay for
Documentation, before a single asset moves.
Even if you paused after the Document stage, you'd be left with something most estates never had: complete, current documentation of what your pipelines actually do.
Key-person risk, gone
The knowledge lives in the knowledge base, not in one expert's head. Lose the expert, keep the migration.
Lineage you can navigate
The Cartographer stitches lineage across every asset into one graph: staging hops, SCD patterns and surrogate keys included.
How it's structured
Every entry follows the same shape.
One asset, one entry, the same fields every time, so a person reviewing it at a gate, or an agent reading it downstream, always knows where to look.
Your legacy estate
DimCustomer.dtsxpipeline.jsonload_sales.ipynbdbo.usp_loadEXTERNAL TABLEvw_ordersadf_triggerfact_sales.dtsxOPENROWSET
SSIS · ADF · Synapse · T-SQL
asset
The canonical name of the legacy asset being documented.
source
Where it came from: the
tool (ssis, adf, synapse, t-sql) and the package or object.documented_by
Which Documenter wrote the entry, so every fact is traceable to its source.
behavior
What the asset actually does: its
pattern, the control_flow steps, and run_semantics (e.g. incremental with a watermark).lineage
Source-to-target lineage from source system through staging to the final mart.
risk
A weighted
score plus the drivers that make the asset risky to migrate.targets
Where it maps on the chosen platform and flavor (e.g.
fabric-dbt).status
Live migration state: the
stage, the iteration count, and the last_fix applied in the loop.gates
The human sign-off state at each of the three gates: assessment, design, promotion.
Who writes it, who reads it
Written once, read by everyone.
The Documenters write the entries; the Librarian curates them; the Cartographer links them. From there the Architect designs against it, the builders generate from it, the Test agents check against it, and the Operators log their iterations back into it. When the platform is built, the Chronicler turns it into the documentation your team keeps.
And because the status and gates blocks travel with each entry, the knowledge base is also where your experts see exactly what's been signed off and what's still pending. See how the validation gates work →
Good questions
The knowledge base, answered.
Is the knowledge base ours?
Yes. It documents your estate and is delivered to you: entries, history and all. Your packages, pipelines and data are analyzed for your migration only, never used to train models.
What format is it in?
Structured, human-readable entries (one per asset) versioned in a repository you can browse and diff. Each entry follows the same shape, so a person or an agent always knows where to look.
Does it cover every source?
Every documented asset across SSIS, Azure Data Factory, all four Azure Synapse workloads and T-SQL. The Cartographer then stitches them into one lineage graph spanning the whole estate.
What happens to it after the migration?
It stays yours and becomes living documentation. The Chronicler turns it into a data dictionary, lineage docs, runbooks and onboarding guides for the new platform, so the project ends with documentation, not tribal knowledge. See what you keep →
How is it kept consistent across hundreds of assets?
The Librarian curates it: deduplicating overlapping findings, cross-linking related assets, and versioning every entry so a change is never silently overwritten. It also answers the other agents' questions about the estate.
Let's talk
Want your estate documented?
The estate assessment fills the knowledge base for a representative slice of your estate, so you can see, before you commit, exactly what the fleet found.
Plan my migrationA short form, no spam. We usually reply within one business day.