Azure & Microsoft migration
Azure migration readiness for a 50-person finance firm: a worked scenario
Not a case study — we don't have one for this yet. This is the assessment's own thinking, applied step by step to a firm shaped like the ones we actually see.
This post is part of Azure & Microsoft Migration.
A firm shaped like this — not a real one
We do not have a published case study for a finance-firm migration yet; the only client studies on this site will exist once a real client gives written permission (seeCase Studies). What we do have is a repeatable assessment, and the most useful way to show how it thinks is to run it against a scenario instead of a checklist. So: picture a firm shaped like this. It is not a real client, named or disguised — it is a composite, built from the patterns this kind of estate actually shows, used here because the reasoning is easier to follow attached to specifics than floating free of them.
Step one: inventory, not guesswork
The assessment starts read-only: discovery and dependency mapping across servers, databases, applications, network paths, identity and backups — not a conversation with whoever answers the phone about "roughly what we run." In this scenario that surfaces the predictable thing it almost always does: three of the thirty servers have no owner anyone on the current team can name, and one of them turns out to be a dependency for the loan-origination application's nightly batch job. That is exactly the kind of finding an assessment exists to catch before a migration date is set, not during the cutover weekend.
Step two: a recommendation per workload, not one answer for everything
Every workload gets one of five honest recommendations — rehost, re-platform, replace with SaaS, rebuild, or leave where it is. For this scenario:
- The two SQL Server 2016 instances are the loudest deadline in the estate — support ended 14 July 2026 (seeour post on the four real options). One database is a straightforward application backend: re-platform to Azure SQL Database and stop planning around a version number entirely. The other feeds reporting that a third-party tool queries directly against the file system — that one rehosts to an Azure VM for now, with re-platforming scheduled as a second wave once the reporting tool's vendor confirms compatibility.
- The loan-origination application only supports on-premises deployment. Recommendation: leave it where it is, on a smaller, right-sized on-premises footprint, and revisit when the vendor ships a supported cloud path — not because moving it is impossible, but because moving it today would mean running unsupported configuration on a system that touches regulated data.
- File shares and print/utility servers rehost cleanly to Azure Files and Azure VMs respectively — low risk, low drama, and a good first wave.
"Leave it where it is" is a real recommendation, not a hedge — a hypothetical scenario is the easiest place to be honest about that, since there is no fee on the line for saying it.
Step three: sequencing, smallest blast radius first
The migration plan sequences in waves, and the wave order in this scenario follows the standard rule: reversible and low-consequence first, so the team learns whether the process works before anything that would actually hurt is on the table.
Wave 1 — file shares and utility servers. Low risk, easily reversible, and a real rehearsal of the process end to end: replicate, rehearse the cutover, cut over inside an approved window, run in parallel briefly, sign off.
Wave 2 — the clean SQL Server 2016 database. Re-platform to Azure SQL Database. Application testing happens against the rehearsal environment before any date is fixed, and the cutover only proceeds if the rehearsal passes.
Wave 3 — the reporting SQL Server instance. Rehost to an Azure VM once the third-party reporting tool is confirmed compatible; re-platforming stays on the roadmap as a follow-on project rather than being forced into this wave.
The loan-origination application and its dependent server stay out of every wave in this plan — deliberately, per the "leave it where it is" recommendation above, with a note to revisit at the vendor's next roadmap update.
What the assessment actually produces
For a firm shaped like this, the assessment's written output is the same six things it is for any estate: a dependency map including the connections nobody had documented, a workload-by-workload recommendation like the ones above, a costed Azure run-rate built from observed utilisation rather than server specifications, a separate one-time migration cost estimate, a risk register naming what could go wrong and who accepted the risk, and the wave plan itself. None of those six is a number we can publish here, because none of them exists for a scenario — they exist only once a real estate has actually been inventoried.
That is the honest limit of a worked scenario: it can show you how the thinking runs, not what your own numbers will be. The only way to get those is the assessment itself, against your actual servers rather than a description of a firm shaped like yours.
Start with the assessment, not the migration.
Book an assessment call30 minuteswith the engineer who would scope the work[PLACEHOLDER: written-summary turnaround, not yet committed]