Preparing applications for continuous modernization
Part 2 of 3: Remediation and reauthorization
Why it matters
- Cloud migration has outgrown the standard seven Rs framework
- Remediation and reauthorization are important to helping organizations modernize their migration strategy
- Addressing migration risk and authorization early can prevent costly delays later
Part 2 of the How Cloud Migration Outgrew the Seven Rs series, examining how today's hybrid, multicloud and mission-driven environments require additional migration strategies that complement the original framework.
Remediation: The migration strategy that makes the others possible
In most cloud migration frameworks, remediation is treated as prep work that happens before the "real" migration strategy begins. That's a mistake.
Remediation is the work required to make a workload eligible for another migration strategy. Whether the destination is rehost, replatform, refactor, retain, or retire, remediation makes the application safe, stable, and understandable enough to move.
Ignoring remediation doesn't eliminate the work. It simply turns planned work into unplanned work, and unplanned work tends to surface when teams are already under pressure.
How cloud discovery identifies remediation priorities
Remediation candidates usually emerge during discovery.
Sometimes the evidence comes from automated vulnerability scans. Other times, it comes from the equally important process of talking to the people who have kept the application running.
Those conversations often reveal brittle dependency chains, undocumented integrations, configuration drift, tightly coupled components, and stateful designs that won't survive a new operating model.
Not every finding needs to be fixed before migration. That kind of absolutism is how remediation becomes a black hole. Every material finding, however, must be understood, triaged, assigned, and documented.
Critical vulnerabilities with active exploit paths may require immediate remediation. High-severity findings may need to be resolved before the workload enters a migration wave. Medium- and low-severity findings can often be accepted temporarily—provided they have an assigned owner, appropriate compensating controls, and a documented date for re-evaluation.
That distinction matters because remediation has two common pitfalls.
What are the risks of poor cloud migration remediation?
The first pitfall is scope creep.
A patching effort becomes an architecture review. The architecture review becomes a refactor debate. The refactor debate becomes a replatforming proposal. Six weeks later, the workload has not moved, and nobody can explain what “done” means. Remediation needs clear exit criteria.
The second pitfall is fixing symptoms while preserving causes. Rotating a hard-coded password is necessary. Moving secrets into a secrets manager is remediation. Patching a vulnerable package is necessary. Creating a dependency management practice that prevents eighteen-month-old vulnerabilities from lingering in production is remediation.
One of the hardest things to contend with is time.
Migration schedules are often approved before discovery reveals the portfolio’s true condition. When the data shows how many workloads need weeks or months of remediation, leaders have three legitimate choices: change the schedule, change the scope, or change the risk posture. Pretending there is a fourth option (i.e., move everything anyway) often substitutes the appearance of acceleration for actual risk management.
What makes a workload ready for cloud migration?
Quality remediation produces a migration-ready workload with a documented risk posture. Success resembles resolved critical issues, removed blockers, mapped dependencies, externalized configurations, and managed credentials. Last, but not least, accepted risks are recorded with authority and accountability.
Remediation is the inspection that helps you keep your migration from becoming a mess.
What is reauthorization in federal cloud migration?
Reauthorization is the process of reestablishing an application’s compliance posture and legal authority to run after it moves to a new cloud provider, service tier, security boundary, or impact level.
It’s worth noting that application authorization can be very fluid. Whether it’s FedRAMP authorization tiers, DOD impact levels, FISMA compliance frameworks, or CMMC certification requirements, security requirements can change at any time.
Accordingly, reauthorization is key. And in federal environments, it’s important to consider how much work must be performed anew, and how much can be inherited from the target cloud environment’s existing authorization and control implementations.
Why ATOs matter in federal cloud migration
Authorization is often treated as a mundane, late-stage compliance activity. In federal cloud migration, that mindset introduces unnecessary risk. FedRAMP, FISMA, DoD Impact Levels, CMMC, and agency-specific ATO processes are the formal machinery by which the government decides whether risk is understood, managed, and acceptable. Treating them as optional is how workloads end up running in environments where they were never certified. It’s unnecessarily risky and it could destroy your organization’s credibility.
How inherited controls can simplify cloud reauthorization
A cloud provider authorized at the appropriate security level can make life easy by satisfying some infrastructure-layer controls. That inheritance can reduce the work associated with reauthorization, but inheritance is not an excuse for abdication.
The application team still owns system-specific controls, including identity and access management, audit logging, data handling, configuration management, incident response, boundary definition, encryption, and evidence that those controls are working in the new environment.
The size of the reauthorization effort depends on the gap between what the platform provides and what the application must still prove.
What are the three stages of cloud reauthorization?
Reauthorization typically follows three overlapping tracks.
- Documentation
Documentation generates the necessary artifacts for the authorizing official to make an authorization decision. In a well-managed migration program, many of these documents are typically available from the original authorization and may require updates rather than the creation of new content. However, in cases of poorly documented original authorizations, new documents must be created, adding time that may not have been accounted for in the migration timeline. - Technical
The technical stream focuses on implementing and validating the controls necessary for the new environment. Technical includes configuring audit logging according to the specifications required by the impact level, implementing identity and access management in line with framework standards, and validating that data both in transit and at rest is encrypted to meet required specifications. It’s also important to note that the boundaries of the new environment must be clearly defined, documented, and enforced in a way that can be verified during the third stream, assessment. - Assessment
Assessment involves engaging a third-party assessor (or a government review team, depending on the authorization pathway) to conduct an independent evaluation required for the authorization to operate process (ATO). The timeline for this engagement can fluctuate since it’s outside of organizational control, which leads us to the next section.
How reauthorization affects federal cloud migration timelines
Reauthorization can be tedious. A successful migration can still produce a workload that’s deployed, tested, and operationally ready—but unable to operate legally.
That’s not a technical failure; it’s a planning failure.
The hard truth is that federal migration programs optimize deployment velocity within the authorization constraint, not around it. Successful organizations build authorization infrastructure before migration begins.
What is required before a federal workload goes live?
Toward the conclusion of the reauthorization process, your checklist should have:
- An authorization to operate before the workload is needed in production
- A system security plan that reflects the actual environment
- Control implementation validated by an assessor who has reviewed evidence, not assertions
The plan of action and milestones are significant and should include specific findings, remediation owners, actively tracked dates, and a complete package for the authorizing official. It’s also important that the continuous monitoring program is running, collecting evidence, and feeding into the ongoing authorization posture rather than being stood up once for the assessment then abandoned.
Why cloud migration requires continuous portfolio management
Reauthorization is the last formal stop in the expanded framework, but it is not the end of the road. The portfolio that has been rationalized, migrated, rebalanced, remediated, and authorized is not a finished artifact. It is a living system operating in a dynamic environment, and keeping it aligned with mission requirements, cost models, security standards, and authorization postures is ongoing work.
The 13 strategies in this series—built from the original seven plus the six added for real-world complexity—are not a checklist, but a vocabulary. That vocabulary makes decisions easier to communicate across the technical and organizational boundaries that migrations always cross. It also makes those decisions legible to the stakeholders who fund and govern them, and it keeps us honest about the full range of outcomes the analysis may produce. The application is not a problem. Not knowing what it does is.
Continue reading the How Cloud Migration Outgrew the Seven Rs series:
Part 1 | Repatriation and redistribution: Where should your cloud workloads really live?
Part 2 | Remediation and reauthorization: Preparing applications for continuous modernization
Part 3 | Reintegration and rightsizing: Optimizing cloud portfolios for long-term value
Three things to remember
- Remediation makes workloads safe and migration-ready, but must have clear exit criteria to avoid scope creep.
2. Reauthorization reestablishes compliance and legal authority after migration—inheriting some controls, but owning others.
3. Both Rs are important, timeline-sensitive steps in the expanded 13-R cloud migration framework.
