Migrating a Legacy On-Prem Case Management System to the Cloud Without Downtime

The Problem Is Not the Migration. It Is the Gap.

A mid-size county agency running a 12-year-old on-premises case management platform processes roughly 800 case updates per day. The system runs on a single aging Windows Server 2012 R2 box. The vendor stopped issuing security patches 18 months ago. The agency cannot afford a weekend blackout window because caseworkers operate Monday through Saturday and a four-hour outage translates directly to missed court deadlines and delayed benefits.

This scenario is not unusual. Federal and state agencies, as well as commercial insurers and legal operations teams, routinely run case management workloads on hardware that is one failed disk away from a crisis. The migration itself is solvable. The real engineering challenge is the gap between the old system and the new one, specifically keeping data consistent and users productive while both environments run simultaneously.

The approach below is what a structured, zero-downtime migration actually looks like in practice.

Step 1: Inventory Before You Touch Anything

Start with a full dependency map. Legacy case management systems almost always have undocumented integrations: a scheduled task that pushes PDFs to a shared drive, a custom ODBC connector feeding a reporting tool, a batch job that syncs with a court docket API at 2 a.m. Missing one of these will cause a silent data integrity failure that does not surface until a caseworker notices a discrepancy three weeks post-cutover.

Concrete inventory checklist:

• All inbound and outbound API or file-based integrations, with call frequency and payload size
• Database schema version, stored procedures, and any application-level triggers
• Authentication dependencies (LDAP, Active Directory, SAML, or local accounts)
• Average and peak transaction volume per hour, not just per day
• Backup schedule and current recovery point objective (RPO) in practice, not on paper
• Any client-side components such as thick clients, browser plugins, or locally installed report viewers

Document everything in a single runbook. This runbook becomes the source of truth for every subsequent phase.

Step 2: Choose a Migration Pattern That Matches Your Risk Tolerance

Three patterns cover most legacy case management migrations:

Lift-and-Shift (Rehost)

Move the existing application image to a cloud VM with no code changes. This is the fastest path and the lowest risk for the application layer. The tradeoff is that you carry all the technical debt into the cloud. For agencies under a hard deadline (contract renewal, hardware failure risk, compliance audit), lift-and-shift buys time. Azure Migrate and AWS Application Migration Service both support this with near-continuous replication, meaning the cloud VM stays in sync with the on-prem server until the moment of cutover.

Replatform

Move the application to a managed service (for example, migrate a SQL Server database to Azure SQL Managed Instance or Amazon RDS) without rewriting application logic. This eliminates OS-level patching responsibility and often improves performance. It requires more testing because managed services do not support every SQL Server feature, particularly older compatibility levels and some CLR integrations.

Refactor (Phased)

Break the monolith into services over time while running both systems in parallel. This is the right long-term answer for large agencies but the wrong answer if you need to decommission hardware within 90 days. Reserve refactoring for a second phase after the initial migration stabilizes.

For most government case management migrations, the practical answer is replatform the database first, then rehost the application tier, then refactor incrementally over the following 12 months.

Step 3: Build the Parallel Environment and Establish Continuous Replication

Stand up the cloud environment completely before you touch production. This includes networking (VPN or ExpressRoute/Direct Connect back to on-prem), identity integration, storage, and monitoring. Do not skip monitoring setup. You need baseline metrics from day one of parallel operation.

Enable continuous data replication from the on-prem database to the cloud database. For SQL Server workloads, SQL Server transactional replication or Azure Database Migration Service in continuous sync mode both work. The goal is a replication lag under 30 seconds. Measure it. Log it. If lag spikes during business hours, that tells you something about network bandwidth or query volume that will matter at cutover.

Run the cloud environment in read-only shadow mode for at least two full business cycles (typically two weeks). Have a subset of caseworkers run parallel queries against both systems and compare results. Discrepancies at this stage are cheap to fix. Discrepancies discovered post-cutover are expensive and sometimes legally consequential.

Step 4: Migrate Integrations One at a Time

Do not flip all integrations at cutover. Migrate each integration to point at the cloud endpoint during the parallel period, verify it independently, and mark it complete in the runbook before moving to the next one.

For file-based integrations, update the UNC path or SFTP target to the cloud storage endpoint (Azure Blob, S3, or equivalent). For API integrations, update the base URL in the calling system and confirm round-trip latency is acceptable. For scheduled batch jobs, re-deploy them in the cloud scheduler (Azure Automation, AWS EventBridge, or a container-based cron) and run them in dry-run mode against the shadow database before enabling writes.

This incremental approach means that by the time you reach the actual cutover window, most of the integration work is already done and verified.

Step 5: Execute a Controlled Cutover, Not a Big Bang

Schedule the cutover for the lowest-volume window you can find, typically a Sunday evening or a holiday. Even if you cannot afford a full blackout, you can afford a 15-minute read-only window.

Cutover sequence:

1. Put the on-prem application into read-only mode. Caseworkers can view cases but cannot write.
2. Allow replication to drain until lag reaches zero.
3. Verify final row counts and checksums between on-prem and cloud databases.
4. Update DNS to point the application URL at the cloud load balancer.
5. Enable writes on the cloud environment.
6. Confirm a small set of test transactions succeed end-to-end.
7. Notify users that the system is live on the new platform.

Total read-only window in a well-prepared migration: 10 to 20 minutes. That is achievable even for agencies that cannot schedule a maintenance window during business hours.

Step 6: Keep the On-Prem System on Standby for 30 Days

Do not decommission the old server the day after cutover. Keep it powered on, with replication stopped but data intact, for at least 30 days. If a critical issue surfaces (a missing stored procedure, a report that breaks, a batch job that was not in the inventory), you have a fallback. After 30 days of stable cloud operation, decommission with confidence.

Common Failure Points to Avoid

• Skipping the dependency audit: One undocumented integration will break something post-cutover.
• Underestimating replication lag: A 5-minute lag at cutover means 5 minutes of potentially lost writes if the on-prem system is taken offline too early.
• Changing too much at once: Migrating and upgrading the application version simultaneously doubles the blast radius of any failure.
• No rollback plan: Define the specific conditions that trigger a rollback before you start the cutover sequence, not during it.

Takeaway

Zero-downtime migration of a legacy case management system is an engineering problem, not a vendor selection problem. The work happens in the weeks before cutover: dependency mapping, parallel environment validation, incremental integration migration, and replication monitoring. By the time you flip DNS, the migration should already be 90 percent complete. The cutover window is just the last 10 percent.

If you are planning a case management migration and want a second set of eyes on your runbook or architecture, reach out for a brief working session with the IT Custom Solution team. We have executed these migrations for both government and commercial clients and can help you identify gaps before they become incidents.