The migration ends. The documentation doesn't.
Most migrations finish with a working platform and a documentation debt. This one finishes with both: the platform, and a living layer of documentation around it. Source-to-target lineage, a data dictionary, navigable transformations and data-quality tests, generated as the build happens and yours to keep.
The output side of the knowledge base.
The knowledge base documents your legacy estate: what your pipelines do today. This is the other end of the same story: your new platform, documented. As the builders generate the assets, the Cartographer stitches the lineage and the Chronicler writes the dictionary and runbooks, so the platform arrives explained, not just running.
- Every table traced from the old estate to its new home
- Generated from the build, not written up afterwards
- Flavor-agnostic: the same lineage and docs in dbt or your own framework
- Delivered into your repository and catalog: it's yours
A sample: every model traced from source system to final mart, the whole estate as one graph.
Six things you keep, not six slides you're shown.
Each one is a real, generated artifact that ships with the platform and outlives the project. Follow any card to go deeper.
Source-to-target lineage
Trace your data from source system to final mart: staging hops, SCD patterns and surrogate keys included.
Explore →A data dictionary
Every table and column, defined and searchable, written by the Chronicler as the platform is built.
Explore →Navigable transformations
Step from any mart table back through staging to the source query. The logic is documented, not a black box.
Explore →Data-quality tests
Not-null, unique, relationship and parity tests that ship with the build and flag failures and warnings.
Explore →Living documentation
Runbooks and onboarding guides, generated from the build, so they stay true instead of going stale.
Explore →Master data tooling
WorkbookConnect: manage custom mappings and groupings in Excel, and clean up legacy for good.
Explore →Chat with your data
Modeled, documented, governed data your team can question in plain language with Fabric Copilot or Databricks Genie.
Explore →Choosing your own framework instead of dbt? We port all of this into it, which is extra effort on our side, and you still keep every piece. dbt or your framework →
By default you get tables. You also keep the map.
A lift-and-shift, or the platform's own defaults, move the data and leave the understanding behind. The difference isn't the platform. It's what you can still explain a year later.
A lift-and-shift, or platform defaults
- DocumentationWhatever survived in people's heads
- LineageReconstructed by hand when something breaks
- Data qualityDiscovered in production
- OnboardingShadow a senior engineer for weeks
What the fleet leaves you Plainsight
- DocumentationA data dictionary, generated and current
- LineageNavigable, source to target, across the estate
- Data qualityTests that ship with the build
- OnboardingDocs a new hire can read on day one
You'd get the platform either way. The understanding of it is what you keep.
Written by the fleet, owned by you.
The Cartographer stitches the lineage; the Chronicler writes the data dictionary, runbooks and onboarding guides as the platform is built; the Test agents and the Reconciler generate the data-quality tests. Everything they produce lands in your repository and your platform's own catalog, never a portal you rent from us.
And because the tests run inside the build-test-run loop, the documentation keeps pace with the platform rather than lagging behind it. See how the loop works → · how the gates work →
Not slides. The actual generated artifacts.
Real output from a dbt build: the lineage graph, the searchable catalog and the documented BI consumers. Click any image to enlarge.
What you keep, answered.
Is the documentation ours?
Yes. It is generated into your repository and your platform’s own catalog, and delivered with the migration. Your code and data are analyzed for your migration only, never used to train models.
How is this different from the knowledge base?
The knowledge base documents your legacy estate: the input. This is your new platform documented: the output, with lineage, a data dictionary, tests and runbooks for what you actually run. The source-to-target lineage is the bridge between the two.
Does it stay current after go-live?
It is generated from the build, so it regenerates when the build changes, and the data-quality tests run on every pipeline run. The documentation and the guarantees move with your platform instead of rotting into a stale wiki.
Do we need dbt for this?
No. The dbt flavor ships dbt docs and dbt tests; in your own framework the Chronicler and the Cartographer generate the same lineage, dictionary and tests into your repo and catalog. Either way, you keep them. dbt or your own framework →
Where does it actually live?
In your Git repository and, where the platform supports it, its native catalog: Microsoft Purview and the OneLake catalog on Fabric, Unity Catalog on Databricks. Browsable by your team, diffable in version control.
Want to see what you'd keep?
The estate assessment documents a representative slice of your estate, so you can see the lineage, the dictionary and the tests you'd be left with before you commit.
Plan my migrationA short form, no spam. We usually reply within one business day.