DoD has invested significantly in Software Factory infrastructure — Platform One, Kessel Run, Army's Enterprise Cloud Management Agency, and numerous program-specific factories. These factories were built to accelerate new application development. Migrating legacy applications to cloud through these factories — rather than just building new — is the harder, higher-value work that most programs eventually face.
The Legacy Application Reality in DoD
DoD runs thousands of legacy applications that were not designed for cloud deployment. Common characteristics: - Monolithic architecture with tightly coupled components - Stateful deployment that assumes specific hardware - Direct database connections rather than service-oriented APIs - Authentication tied to on-premises Active Directory - Binary dependencies on specific OS versions or middleware - No automated test suite
Migrating these applications to cloud is not a lift-and-shift exercise. It requires architectural work, and doing that work while maintaining operational availability of the legacy system demands careful migration sequencing.
The Application Portfolio Assessment
Before any migration begins, assess the application portfolio using a structured framework. A common government adaptation of the Gartner "5R" framework:
Rehost (Lift and Shift): Move the application as-is to cloud infrastructure with minimal changes. Achieves cloud cost and operational benefits without modernization investment. Appropriate for applications that are stable, low-priority for modernization, and close to end-of-life.
Replatform: Migrate to cloud-native infrastructure (managed databases, containers) with minimal code changes. Example: Move from Oracle on-premises to Amazon RDS. More cloud benefit than rehost without full refactoring cost.
Refactor/Re-architect: Redesign application components as cloud-native services. The highest investment but produces the most cloud-native, scalable, maintainable result. Appropriate for mission-critical applications with long operational lifespans.
Retain: Keep the application on-premises or in the current environment. Appropriate for applications with regulatory constraints, end-of-life timelines, or functional requirements that don't benefit from cloud migration.
Retire: Decommission the application and migrate users to an alternative. Reduces total portfolio size and licensing cost.
A portfolio assessment of 50 legacy DoD applications might yield: 15 Rehost, 10 Replatform, 8 Refactor, 10 Retain, 7 Retire. Prioritize by mission impact, technical debt level, and modernization opportunity.
The Strangler Fig Pattern for DoD Applications
The strangler fig pattern is the recommended approach for migrating large, complex legacy applications that cannot be taken offline for a full replacement:
- Identify a bounded slice of functionality that can be extracted and rebuilt as a cloud-native service — start with the least risky slice, not the most complex
- Build the new service in the Software Factory — containerized, API-accessible, with automated tests
- Route traffic to the new service while the legacy system continues to operate — a routing layer (API Gateway, reverse proxy) directs specific requests to new or legacy handling
- Validate at scale — operate both in parallel until the new service is proven
- Retire the legacy component corresponding to the migrated slice
- Iterate — repeat with the next slice
The legacy system is "strangled" over time as its functional scope shrinks and eventually reaches zero. No big-bang migration cutover, no single point of catastrophic failure.
Integrating Legacy Applications with Software Factory Pipelines
Legacy application code often lacks the automated test coverage, clean build processes, and configuration management needed to onboard to a Software Factory CI/CD pipeline. Minimum pipeline onboarding requirements:
Build automation: Automate the build process — ideally containerizing the application, or at minimum producing repeatable automated build artifacts. Manual build steps that require specific developer machine configurations must be eliminated.
Baseline test coverage: Even 20–30% unit test coverage is better than zero. Start with tests for the most critical business logic. The CI pipeline cannot enforce quality gates with zero automated tests.
Configuration externalization: Hardcoded configuration (database connection strings, API endpoints, environment-specific settings) must be externalized to environment variables or secret management. This is the most common blocker when containerizing legacy applications.
Security baseline: Run SAST on the codebase before pipeline onboarding to identify and prioritize security debt. Some findings will be accepted risk with documentation; critical findings should be remediated before the application goes into the pipeline.
Common DoD Cloud Migration Pitfalls
Treating cloud as a hosting environment: Programs that move applications to cloud but retain all the operational patterns of on-premises (manual change control, operator-administered deployments, static IP dependencies) don't achieve cloud benefits. Cloud migration must come with process modernization.
Security authorization lag: Applications that migrate to cloud still need updated ATOs reflecting the cloud boundary. Starting the ATO process late in a migration creates operational risk when the migration completes before authorization catches up. Engage the ISSO and AO at the start of migration planning.
Data migration underestimated: Moving terabytes of legacy database content to cloud-compatible formats (schema migration, data type compatibility, encoding normalization) routinely takes 2–3x longer than estimated. Plan for data migration as a major workstream.
Ignoring dependencies: Legacy applications have network-level dependencies on other applications that aren't visible from application code — monitoring agents, centralized logging sinks, license servers, time synchronization. Inventory dependencies through network flow analysis before migration.
Skipping the strangler fig in favor of big-bang: Big-bang replacements at DoD scale almost never go as planned. Programs that attempt to replace a complex legacy system all at once frequently face schedule overruns, operational disruption, and quality issues. The incremental strangler fig approach is slower per feature but lower risk overall.
Rutagon provides cloud migration advisory and engineering services for DoD program offices and prime contractors. Contact us to discuss migration strategy for your program.
Frequently Asked Questions
How long does a DoD cloud migration typically take?
Timeline varies enormously with application complexity. A rehost of a single application to GovCloud infrastructure can take 3–6 months including ATO updates. A complex refactor/re-architecture of a mission system with a strangler fig approach may span 2–5 years. Most DoD cloud migration programs should plan for 18–36 months for meaningful portfolio migration of mid-complexity applications.
Can DoD legacy applications be containerized?
Most legacy applications can be containerized with varying degrees of effort. Applications that have clear external dependencies, standard OS requirements, and externalized configuration containerize relatively easily. Applications with deep hardware dependencies (specific serial ports, hardware security modules, proprietary middleware) require more work. A containerization feasibility assessment is the first step — it identifies the specific remediation work needed for each application.
What ATO work is required when migrating to cloud?
Cloud migration changes the system boundary documented in the System Security Plan (SSP). A significant change (moving from on-premises data center to cloud) typically requires an updated SSP and a review by the authorizing official, potentially triggering a new security assessment. The extent of assessment depends on how much the threat model, control implementation, and system boundary change. Engage your ISSO early in migration planning to understand the ATO implications.
How do Software Factories help with legacy migration?
Software Factories provide the tooling, pipelines, and infrastructure that legacy migration requires — container registry, CI/CD pipeline, security scanning automation, and cloud deployment infrastructure. Programs migrating legacy applications to cloud through a Software Factory gain the factory's established compliance posture, reducing the need to build that infrastructure from scratch. The migration team focuses on application modernization work rather than DevSecOps infrastructure work.