Fleet command
runs the mission
- The Conductor
conductor - The Librarian
librarian
Agentic AI migration · Microsoft Fabric & Databricks
Move SSIS, ADF, Synapse & T-SQL to Microsoft Fabric or Databricks.
A fleet of 23 specialized agents documents your legacy estate, designs the target, then builds, tests and operates it on Fabric or Databricks. The loop runs until the tests pass. Your experts sign off at every gate.
Autonomous in the loop. Accountable at the gates.
- Iterates until green
- Open-source dbt or your own framework
- Your code & data stay yours
Your legacy estate
DimCustomer.dtsxpipeline.jsonload_sales.ipynbdbo.usp_loadEXTERNAL TABLEvw_ordersadf_triggerfact_sales.dtsxOPENROWSET
SSIS · ADF · Synapse · T-SQL
0
legacy workloads documented
SSIS · ADF · T-SQL · 4× Synapse
SSIS · ADF · T-SQL · 4× Synapse
2×2
targets × delivery flavors
Fabric & Databricks · dbt or your framework
Fabric & Databricks · dbt or your framework
0
specialized agents in one fleet
each with one job, handing off cleanly
each with one job, handing off cleanly
0
shared knowledge base
behind every design, build and test
behind every design, build and test
The migration tax
Manual migration doesn't scale. And the risk shows up late.
Modernizing a Microsoft data estate still mostly happens by hand. Someone reads through hundreds of pipelines and stored procedures, then rebuilds them on Fabric or Databricks. It's slow, and most of what makes it work lives in a few people's heads. Worse, the hardest components tend to surface right before the deadline, exactly when they cost the most to fix.
- Weeks of manual inventory before a single asset moves
- Complexity judged by gut feel, not data, so plans slip
- High-risk packages discovered late, not early
- Delivery scales linearly with team size, not ambition
- Key-person risk: lose the expert, lose the migration
From tedious to a factory
The same migration, re-engineered as a fleet.
The fleet inventories your assets, scores their complexity and documents what they actually do, then builds, tests and runs the result on the platform you choose. Same migration, re-engineered: a loop that corrects itself instead of a backlog that keeps growing.
Traditional migration
- Estate discoveryManual inventory, weeks of analysis
- ComplexityExpert judgment, inconsistent
- Pattern selectionTrial-and-error per platform
- RiskOften surfaces late in the project
- PrioritizationSpreadsheet exercises
- ScalabilityLinear with team size
- KnowledgeKey-person risk
- Defect handlingSurfaces in UAT
Agent-fleet migration Plainsight
- Estate discoveryAutomated documentation in minutes
- ComplexityAgent-scored, repeatable
- Pattern selectionVerified mappings to Fabric or Databricks
- RiskFlagged at the start, by the Surveyor
- PrioritizationData-driven backlog generation
- ScalabilityFactory-style parallelization
- KnowledgeCodified in the knowledge base
- Defect handlingCaught and fixed in the loop, automatically
The payoff: you start faster, plan with real numbers, spend less, and your team doesn't fall apart when one expert leaves. On Fabric or Databricks.
How it works
Five stages. Three gates. One inner loop.
Document → Architect → Build → Test → Operate. Agents iterate autonomously inside the build-test-run loop; your experts approve the three gates that matter.
01
Document
Documenters reconstruct the functional behavior of every legacy asset into the knowledge base; the Surveyor scores complexity and prioritizes the backlog.
Gate 1 Assessment
02
Architect
The Architect turns the knowledge base into a Target Design Spec, applying your naming, error-handling and orchestration standards.
Gate 2 Design
iterates until green
03
Build
Builders generate the assets for the chosen platform and flavor.
04
Test
Test agents and the Reconciler verify the generated assets against the documented legacy behavior.
05
Operate
Operators deploy and run in DEV; failures go back to the builders and the loop repeats until the suite is green.
Gate 3 Promotion → DEV · ACC · PRD
The loop that closes itself
Failures don't go on a list. They go back to the builders.
This is the headline feature. The Operator deploys to DEV and runs the pipelines for real. The Test agents and the Reconciler flag what doesn't match the documented legacy behavior. The builders patch it, and the loop runs again. It repeats autonomously until the suite is green, and every iteration is logged in the knowledge base.
- Operator runs the build in DEV and reads every failure
- Test agents and the Reconciler compare against documented behavior
- Builders patch; the loop re-runs, no human in the inner loop
- Every iteration is logged, so "green" is provable
iter 1✗ row-count delta in SCD backfill: 1,284 rows short
iter 2✗ effective-dating off by one on late-arriving keys
iter 3✓ reconciler delta 0 · schema parity 124/124
Green on iteration 3: patched by the builder, verified by the Reconciler
Modular, multi-agent architecture
Meet the fleet: 23 specialists, one mission.
Narrow agents beat one general model: each has one job, one input contract, one output contract. The Conductor sequences them; the knowledge base is their shared memory.
The knowledge base
Your legacy estate, finally documented.
Every Documenter writes structured functional specs into one shared, versioned knowledge base, and everyone downstream reads from it: the Architect, the builders, the Test agents, the Operators. So before a single asset moves, you already have something most estates never had: honest, current documentation of what your pipelines actually do. That alone kills key-person risk.
Behavior, not labels
Control flow, data flow, run semantics and SQL logic, reconstructed from the native definition.
Lineage included
Source-to-target lineage across staging hops, SCD patterns and surrogate keys.
Risk, scored
Script logic, dynamic SQL and unsupported connectors flagged with a weighted score.
Versioned & yours
The Librarian curates and versions every entry. The knowledge base is the customer's.
# 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
What you're left with
The migration ends. The documentation doesn't.
A lift-and-shift hands you working pipelines and not much else. The fleet hands you the platform plus a living layer around it: source-to-target lineage, a data dictionary, navigable transformations and the tests that guard them. It's generated as the build happens, so it's accurate on day one, and it's yours to keep.
- Lineage you can navigate, source system to final mart
- A data dictionary for every table and column
- Data-quality tests that keep guarding the data after go-live
- Docs that stay true because they're generated, not hand-written
- Data you can chat with, via Fabric Copilot or Databricks Genie
A sample: every model traced from source system to final mart, the whole estate as one graph.
Two destinations, two flavors
Two destinations, both first-class.
The fleet documents once (the knowledge base doesn't care where you're going) and builds for the platform and flavor you choose.
Microsoft Fabric
dbtyour framework
dbt For teams standardizing on dbt, the open-source standard that's free to run. The builders generate a full dbt project, your layers, your macros, your tests.
your framework For teams that built their own way of working over the years. The builders generate into your existing patterns, naming, error handling and orchestration.
Migrate to Fabric → Databricks
dbtyour framework
dbt For teams standardizing on dbt, the open-source standard that's free to run. The builders generate a full dbt project, your layers, your macros, your tests.
your framework For teams that built their own way of working over the years. The builders generate into your existing patterns, naming, error handling and orchestration.
Migrate to Databricks →Not sure which? Compare Microsoft Fabric and Databricks →
dbt or your own framework? See when to choose which →
SQL Server Integration Services◆Azure Data Factory◆Azure Synapse Analytics◆T-SQL, stored procedures, views & functions◆→ Microsoft Fabric◆ → Databricks◆ SQL Server Integration Services◆Azure Data Factory◆Azure Synapse Analytics◆T-SQL, stored procedures, views & functions◆→ Microsoft Fabric◆ → Databricks◆
High-fidelity outputs
Every step produces an artifact your team can review.
Nothing is a black box. The fleet emits structured, inspectable outputs at each control point, from estate scoring to a validation report with its iteration log. The three artifacts below are illustrative samples, not one customer's data.
Complexity scorecard
estate_scan.summary · sample Low 128 Medium 137 High 47
Dynamic / parameterized SQL 0.31
Script Tasks (.NET) 0.24
Unsupported connectors 0.18
Parameter sprawl 0.14
Target Design Spec
dim_customer.tds · sampleBRONZEraw.crm_customerCopy / ingest
SILVERstg_customerstaging model
GOLDdim_customerSCD2 snapshot
GOLDfct_ordersincremental MERGE
GOVERNgrantsUnity Catalog / OneLake RBAC
SCD Type 2, error rows routed to a reject table
Validation report
run #0428 · sample Schema parity (source vs target) 124/124
Row-count reconciliation delta 0
SCD Type 2 effective dating ok
Null and key integrity ok
Dynamic SQL block review
Iterations to green 3
Ready for sign-off, 1 item flagged for review
Accountable at the gates
Autonomous in the loop. Accountable at the gates.
Agents iterate autonomously inside the build-test-run loop in DEV. That's the whole point of the Operators. But three gates stay mandatory and human: this is where your experts hold the migration accountable.
Gate 1 · Assessment
Your experts sign off the knowledge base + complexity scorecard, then the Architect designs the target.
Gate 2 · Design
Your experts sign off the Target Design Spec, then the builders generate the assets.
Gate 3 · Promotion
Your experts sign off the validation report + iteration log, then promotion through your existing DevOps process.
Why teams choose this
Faster start. Predictable delivery. Standards that survive.
Documentation in minutes
Automated documentation replaces weeks of manual inventory, and you keep the docs.
Predictable planning
Consistent, agent-scored complexity turns guesswork into a data-driven roadmap.
Self-correcting builds
The build-test-run loop catches and fixes defects automatically, before UAT.
Standards that survive
dbt or your framework: your conventions are the spec, not a casualty of the move.
No black boxes
Inspectable artifacts at every step: knowledge base, Target Design Spec, validation reports.
Resilient teams
Codified intelligence removes key-person risk and keeps knowledge in the fleet.
Good questions
What teams ask before they start.
Is the migration fully automated?
Inside the build-test-run loop, yes. Operator agents deploy to DEV, run the pipelines, diagnose failures and route fixes back to the builders, then re-run, iterating until the tests pass, without waiting on a human. Around the loop, no. Your experts approve three gates: the assessment after documentation, the target design, and promotion toward production. Autonomous in the loop; accountable at the gates.
Which source platforms do you support?
Seven legacy workloads: SSIS, Azure Data Factory, T-SQL (stored procedures, views and functions), and all four Azure Synapse workloads: pipelines, notebooks, dedicated SQL pools and serverless SQL. Each is read by a specialist Documenter that reconstructs what the asset actually does into the knowledge base.
Fabric or Databricks, which should we pick?
Both are first-class targets, and the right answer depends on your estate and your strategy. Because the Document stage is target-agnostic, you can document first and decide with evidence. The Surveyor's complexity scorecard turns the question into numbers for your estate. We stay neutral until your data isn't. Compare Microsoft Fabric and Databricks →
We already use dbt.
Then the builders generate dbt: your layers, your macros, your tests, on Microsoft Fabric or Databricks. The dbt flavor is for teams standardizing on dbt, and the generated project is meant to look like one your team would have written.
We built our own framework over the years.
It survives. The Architect encodes your conventions (naming, error handling, orchestration) into the Target Design Spec, and the builders generate into your existing patterns. That is the whole point of the your-framework flavor: the years you spent building your way of working are an asset to keep, not a casualty of the migration.
What's in the knowledge base, and who owns it?
Structured functional specs of every documented asset: its behavior, lineage, risk score and migration status. It is yours. And it doubles as the documentation your estate never had: complete, current documentation of what your pipelines actually do, delivered even before a single asset moves.
What if an agent gets something wrong?
That is what the loop is for. Test agents and the Reconciler compare generated assets against documented legacy behavior, Operators surface runtime failures, and the builders patch and re-run until the suite is green. Nothing passes the final gate without a validation report (including its iteration log) that your experts sign.
How do assets reach production?
Through your existing DEV → ACC → PRD DevOps process. Agents iterate to a green build in DEV; the validation report then supports business sign-off before the assets promote through your own pipeline. The fleet fits your release process; it doesn't replace it.
How is security and governance handled on the target?
It is part of the Target Design Spec, not an afterthought. Source permissions and identities are mapped to the target's native model: Unity Catalog catalogs, grants and lineage on Databricks, or workspace roles and OneLake security on Microsoft Fabric, with access governed through Microsoft Entra ID. The Architect records the intended grants at the design gate, so your security owners approve them before anything is built.
Is our code used to train models?
No. Your packages, pipelines and data are analyzed for your migration only. They are never used to train models, and your IP stays yours.
Getting started
From first call to a migration plan in three steps.
No procurement marathon, no big upfront commitment. We start small, prove the approach on your own estate, and only then scope the full migration.
- 01
Discovery call
A short conversation about your SSIS, ADF, Synapse or T-SQL landscape and what a successful move to Fabric or Databricks looks like for you.
- 02
Estate assessment
The Surveyor documents a representative slice of your estate and hands back a complexity scorecard and a clear risk map.
- 03
Tailored migration plan
A prioritized, data-driven roadmap with effort, risk and a predictable, gated path to your chosen platform.
Your IP stays yours
Your packages and pipelines are analyzed for your migration, never used to train models.
Experts at the gates
Human sign-off is mandatory at assessment, design and promotion.
Fits your process
Assets promote through your existing DEV → ACC → PRD DevOps pipeline.
Book my discovery call A short form, no long questionnaires. We usually reply within one business day.
Let's talk
Ready to migrate to Fabric or Databricks?
Tell us about your SSIS, ADF, Synapse or T-SQL estate and we'll share our approach, success stories, and how the agent fleet would apply to you.
Plan my migrationA short form, no spam. We usually reply within one business day.