Legacy Migration Roadmap

A "fully integrated" legacy application is one that doesn't live in isolation — it has scheduled jobs feeding other systems, reports built on top of its tables, other applications querying it directly, and authentication tied to on-prem infrastructure. None of that shows up by just looking at the application's own code, which is why the roadmap for moving one of these to Azure has to start with discovery, not with picking a target database. Microsoft's Azure Migrate service exists for exactly this: it profiles the existing data estate and produces target-platform recommendations, sizing, and cost estimates before anyone commits to a migration plan.

The roadmap

1. Assess and map every integration. Run a discovery pass against the on-prem estate to catalog not just the primary database, but everything touching it — linked servers, SQL Agent jobs, SSIS packages, SSRS reports, file shares, and any other application with a live connection. For a fully integrated app, this step is what prevents an integration from silently breaking weeks after cutover.
2. Choose the data target. Relational data with existing joins, transactions, and SQL Server compatibility generally maps cleanly onto Azure SQL Database. Schema-flexible, high-throughput, or globally distributed workloads — session state, activity feeds, catalogs, telemetry — are usually a better fit for Cosmos DB's document model and per-region low-latency reads. Many real migrations don't force everything into one model: core transactional data stays relational in Azure SQL Database while high-volume or variable-shape data moves to Cosmos DB, each running in the database engine it's actually suited for.
3. Migrate the data. For an Azure SQL Database target, Azure Database Migration Service handles large or complex moves with minimal downtime; smaller databases can move with lighter tools like BACPAC export/import or transactional replication where near-zero downtime matters. Moving into Cosmos DB is a different exercise — relational tables typically get reshaped into denormalized documents before they land, since the two engines model data fundamentally differently.
4. Rebuild what doesn't move automatically. SQL Agent jobs become elastic jobs, SSIS packages redeploy to Azure Data Factory's SSIS integration runtime, SSRS reports migrate into Power BI paginated reports, and on-prem Windows logins get replaced with Microsoft Entra ID authentication. On a fully integrated app, these are usually the pieces other systems actually depend on — skipping them is how a migration looks done and then quietly breaks a downstream report or job.
5. Cut over with a rollback path. Stage the new environment, run it in parallel with the legacy system where the migration method allows (replication makes this straightforward), validate the integrations mapped in step one against the new environment, then cut over — with a defined path back to the legacy system if something doesn't hold up.

How CloudCompass AI approaches a legacy migration

We start every legacy migration with the integration map, not the database engine — identifying every job, report, and connected system before deciding whether the target is Azure SQL Database, Cosmos DB, or a split between the two. That ordering is deliberate: picking the database first and discovering the integrations afterward is how migrations end up needing a second, unplanned project to fix what broke.

The roadmap itself — map integrations first, choose the data target second, migrate, rebuild what doesn't move automatically, then cut over with a rollback path — is the same regardless of destination. On AWS that's the same five steps targeting RDS or DynamoDB with the Database Migration Service; on Google Cloud it's Cloud SQL or Firestore with Database Migration Service. The depth here is Azure because that's where we've actually run it.