The decision in front of you
Fabric or AWS? We are not going to tell you which.
We do not need to know which to be useful. The decisions that matter most — who owns each dataset, what counts as trusted, what is sensitive, how long you keep it — are about your business, not your cloud. They are true whichever you pick, they are the input the choice needs, and they are far cheaper to agree before a migration than to retrofit after one.
Two roads, same destination
One slab, or a stack of bricks
Microsoft Fabric
One SKU. Fewer decisions. The shortest path from the Power BI you already run, and Microsoft's release cadence, for better and worse.
AWS
More parts. More control. Better economics at scale, and more engineering time, which is the constraint if you have one analyst.
Both give you storage, compute, pipelines, permissions and a technical catalogue. Fabric leans on Purview and Entra ID for its governance layer; AWS on Lake Formation, IAM and DataZone. Both are strong on identity and audit at the platform level, and thin on anything that needs a human decision recorded.
Decisions about your business, not about your cloud
The work that survives the decision
The left-hand list is usually the one nobody is working on. If you have not chosen yet, it makes the choice easier. If you have, it makes the build smaller. If you are already live, it is what stops the drift.
True whichever you pick
- Who owns each dataset
- What your trust tiers mean
- What counts as sensitive
- How long you keep things
- Who approves access
- What "revenue" means
- Who does what when it breaks
- What your people need to know
- What order you do it in
This is what Lake On Rails holds.
Decided by the platform
- — ETL tooling and orchestration
- — Permissions model
- — Storage layout and table format
- — Cost model and sizing
- — Lineage tooling
The shorter list, and the one your implementation partner is actually good at.
Why the order matters
The difference isn't the work. It's who is still in the room.
Decide it now
The people who know why a report exists, what the number means and which source to trust are still here, and still remember.
Decide it after the build
You are asking an implementation partner to guess, and then you are living with their guess, on everything they migrated.
It is the same decision either way. Nothing about it gets easier by waiting, and the answers get harder to find.
In the product
The same ten capabilities, mapped onto each platform
The left column is what your cloud already covers; the product adds nothing to those rows, so you do not pay twice. The right column is the part that needs a human decision recorded, and each row there links to the screen where you close the gap. Switch the tab from Fabric to AWS and the right column is identical.
Where you connect a platform, Lake On Rails reads technical metadata from Fabric and Purview, or from the AWS Glue Data Catalog, on a schedule. Dataset names, schemas, owners, refresh times. Never the contents.
Our platform-specific guidance is deepest for Fabric today, and the AWS content is being expanded. The operating model itself does not care.
Questions we get on this
Straight answers
Will you recommend a platform if we ask?
We will tell you what each is good at and where each will cost you engineering time, and we will be honest about what your existing skills point towards. We will not put our thumb on the scale, because taking a side would undermine the point of the product: an operating model that holds whichever way you go. Scorchsoft does build on both, if you want the same team for the build.
We have already chosen Fabric. Is it too late?
No. If the build has not started, the operating model makes it smaller: your partner migrates what has an owner and a purpose, and skips what does not. If you are already live, it is what stops the platform drifting into a copy of every source system. Fabric's own governance layer covers identity, audit and cataloguing well; what it does not hold is who is accountable, what the rules are and whether they are followed.
We are on AWS. Does Lake On Rails work as well there?
The operating model is identical. The Glue Data Catalog connection reads the same technical metadata the Fabric connection does. Where the two differ is in our platform-specific notes and guidance, which are deeper for Fabric today; we are expanding the AWS content. If that matters to your decision, ask, and we will show you exactly where each stands.
Is Lake On Rails a catalogue, like Purview or DataZone?
No. Those are technical catalogues: they discover what exists, capture lineage and classify columns. Lake On Rails records the organisational layer above them — a named accountable owner per dataset, the responsibility matrix, written procedures with approvals, and a measure of whether any of it is happening. If you have a catalogue, keep it; the register can read from it.
Where does Lake On Rails itself run?
Wherever you need it to. The standard service is hosted by Scorchsoft and reads your platform through its published APIs. Where your policy requires it, it runs as a dedicated instance or inside your own Azure subscription, under your own identity and network controls. Deploying it into your Azure does not deploy Fabric; Fabric stays a Microsoft service in your tenant either way. Hosting, residency and our security position are answered in full on the questions page.
The first step costs you nothing
Forty-five minutes with whoever runs your reporting
We tell you honestly whether this is worth doing at all, and roughly what it would take. If the answer is not yet, you will hear that. "Not for us" is a fine outcome, and a better one than a slow maybe.