Solution Atlas
EverydayUser storyConsultative playbook

Our database estate is end-of-life and licensing costs are climbing

Legacy Oracle and SQL Server estates are approaching end-of-support and the renewal quote is unaffordable. Application teams want polyglot databases (relational, document, graph) but the platform team needs governance and a credible migration story per workload class.

Trigger
Database EOL + licensing cost shock.
Good outcome
Azure SQL Managed Instance and Cosmos DB baselines live, migration wave planned per workload, Defender for SQL in place.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·Oracle or SQL Server estate at or past end-of-support
  • ·Renewal quote materially higher than prior term (often 3–4x post-acquisition repricing)
  • ·Application teams asking for polyglot databases (Cosmos, Mongo, Postgres)
  • ·DBA team capacity declining; hiring difficult
  • ·Production database hardware refresh due alongside renewal

Questions to ask

Open-ended, SPIN-style — each one has a reason it matters.

  1. 1.Which database engines and versions are running today, and how many of each?

    WhySizes the estate. Surfaces the EOL slice and the polyglot opportunity.

  2. 2.What is the renewal date and indicative quote for the licensing renewal?

    WhySets the deadline and anchors the business case.

  3. 3.Which application teams are pushing for non-relational databases?

    WhySurfaces the polyglot demand and the app-team frustration behind it.

  4. 4.What is your DBA team capacity versus estate growth?

    WhyDBA scarcity often drives the move to managed services.

    Listen for: “shrinking” · “we cannot hire” · “one DBA per 50 servers”

  5. 5.Which databases are at end-of-support today, and what is the remediation budget?

    WhyForcing-function workloads come first in the migration wave.

  6. 6.What does a database migration project look like under your current tooling?

    WhyReveals the cost of the status quo. Often weeks-to-months per workload.

Baseline → target architecture

TOGAF-style gap framing — what we typically see today, and what the proposed end state looks like. The gap between them is the engagement.

Baseline architecture

Mixed Oracle, SQL Server, and sometimes DB2 / PostgreSQL / MySQL on self-hosted Linux/Windows or appliance hardware. DBA team supports the estate manually. Backup via legacy vendor tooling. Performance monitoring via vendor consoles (OEM, SQL Server Management Studio). No central security posture across the database estate.

Typical concerns

  • ·Licensing renewal repricing exposes margin
  • ·EOL workloads running on unsupported versions
  • ·Application teams blocked from polyglot patterns
  • ·DBA team hiring difficult; existing team overstretched
  • ·Hardware refresh cycle compounding cost

Capability gaps

  • ·Managed database service per workload class
  • ·Polyglot persistence (document, key-value, graph)
  • ·Unified security posture (Defender for SQL/PostgreSQL)
  • ·Performance and tuning observability
  • ·Migration runbook with engine-by-engine sequencing
Target architecture

Azure SQL Managed Instance absorbs the lift-and-shift SQL Server workloads. Azure SQL Database serves greenfield relational. Cosmos DB handles the polyglot demand (document, key-value, graph). Azure Database for PostgreSQL / MySQL covers OSS workloads. Defender for SQL provides security posture across the estate. Azure Monitor + Query Performance Insights replace vendor tooling.

Key capabilities

  • Managed database services per workload class
  • Polyglot persistence (Cosmos DB)
  • Defender for SQL security posture
  • Unified observability via Azure Monitor
  • Engine-by-engine migration runbook

Enabling SKUs

Resolved in the ‘Recommended cards’ section below.

Architecture decisions

Each decision is offered as explicit options with trade-offs — Hohpe's “selling options” principle. A safe default is noted where one exists.

  1. Decision 1.SQL Server migration shape — lift-and-shift vs replatform vs refactor

    Lift-and-shift to Azure SQL Managed Instance

    When it fitsExisting SQL workloads with SQL Agent jobs, cross-DB queries, CLR — needs Managed Instance compatibility.

    Trade-offsHigher cost than Azure SQL Database; less elastic.

    Replatform to Azure SQL Database

    When it fitsWorkload fits Azure SQL Database feature surface; greenfield or app-rewrite acceptable.

    Trade-offsSome SQL Server features (cross-DB queries, SQL Agent) unsupported.

    Refactor to Cosmos DB or Postgres

    When it fitsApp rewrite already on the roadmap; polyglot demand strong.

    Trade-offsSignificant engineering effort; multi-quarter timeline.

    Default recommendationLift-and-shift to Managed Instance for legacy workloads; greenfield on Azure SQL Database; refactor case-by-case when app rewrites are independently planned.

  2. Decision 2.Database service tier — General Purpose vs Business Critical vs Hyperscale

    General Purpose

    When it fitsMost workloads. Read/write performance adequate.

    Trade-offsNo read replicas; latency sensitive to compute size.

    Business Critical

    When it fitsLatency-sensitive transactional workloads; read replicas needed.

    Trade-offsMaterially higher cost.

    Hyperscale

    When it fitsVery large databases (10TB+); elastic compute needed.

    Trade-offsDifferent licensing and recovery characteristics.

    Default recommendationGP for most; BC for tier-1 OLTP; Hyperscale only for genuinely large estates.

  3. Decision 3.Migration tooling — Azure Database Migration Service vs offline export-import vs hybrid

    Azure DMS online

    When it fitsProduction workloads with low downtime tolerance.

    Trade-offsSetup complexity; bandwidth-bound.

    Offline export-import

    When it fitsNon-production or workloads with maintenance windows.

    Trade-offsDowntime; cutover risk.

    Hybrid (online for tier-1, offline for the rest)

    When it fitsMixed estate; pragmatic phased approach.

    Trade-offsTwo operational patterns.

    Default recommendationHybrid — Azure DMS online for tier-1; offline for non-production and tier-3.

Low-risk trial — proof of value

8-week database migration foundation — first 5 databases

8 weeks

Estate discovery via Azure Migrate (database assessment). Azure SQL Managed Instance provisioned. First five databases migrated via Azure DMS — mix of tier-1 production (online) and non-production (offline). Defender for SQL enabled. Azure Monitor + Query Performance Insights baselined against the new estate.

Success criteria

  • Five databases migrated with documented downtime within agreed maintenance windows
  • Defender for SQL producing actionable findings on the new estate
  • Query Performance Insights baseline captured for the migrated workloads
  • Migration runbook validated end-to-end with rollback path tested

InvestmentAzure SQL Managed Instance + Azure DMS consumption for the trial scope (~€8–15k/month depending on instance size). Existing on-prem estate untouched until cutover.

Proof metrics

  • ·Migration velocity (databases per week) measured and forecastable
  • ·12-month TCO projection — Azure vs licence renewal
  • ·Application performance at parity or better post-migration
  • ·DBA team operational load reduced via managed-service automation

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

Defender for SQL provides vulnerability assessment, advanced threat protection, and compliance attestation across the migrated estate. Continuous posture replaces the legacy DBA-led review cadence.

Why for this story

Replaces vendor consoles (OEM, SSMS) with unified observability. Query Performance Insights, automated tuning recommendations, and alerting all land here.

Back to Operational data / OLTP modernisation