Lift and Shift Cloud Migration: How to Resolve Security Debt on AWS

The Skip Button Nightmare

At a recent Cloud & DevOps conference, Phạm Thúc Phước, Infrastructure Manager at SupremeTech, opened his keynote with something every engineer in the room had seen a hundred times: a Windows Update notification. Then a Linux patch prompt. Nothing dramatic. Just the small, familiar nuisance of a system asking to be updated.

That was the point. Phước wasn’t there to talk about a rare, exotic threat. He was there to talk about the one risk almost everyone in the audience had personally created, one skip at a time.

His talk walked the room through how that habit compounds into something far more serious, and why his team at SupremeTech has been resolving it through a lift and shift cloud migration rather than patching harder in place.

How Security Debt Builds: The Infinite Loop

Phước opened this part of the talk with the instinct almost every infrastructure team shares: if it’s running well, don’t touch it. It’s not a careless mindset, he pointed out. It comes from a real fear, that applying an update might break something that currently works fine.

But that fear has a cost, and he laid out exactly how it compounds. What most of the room would casually call technical debt, he reframed as a specific, repeating loop:

1. Fear of breaking a stable system
2. That fear pushes some fixes into shadow IT, outside official visibility
3. The team hits postpone on the current patch
4. A new security update arrives before the last one was addressed
5. Security debt increases, and the cycle repeats

He didn’t frame this as a failure of any one team. It’s what happens by default when “stability now” keeps winning against “security later,” update after update, without anyone deciding that on purpose.

Why Delay Turns Patching Into a Gamble

The part of the talk that landed hardest was his explanation of why this loop gets more dangerous the longer it runs, not less. As an organization matures and systems become more interconnected, every postponed patch adds to the pile, and shadow IT grows alongside it. The next update doesn’t get easier to apply. It gets harder, and riskier to leave undone.

At that point, Phước argued, patching stops being routine maintenance. It becomes a gamble: touch a fragile, long-neglected system and risk breaking it, or leave known unpatched vulnerabilities exposed and risk something worse.

What Happens When the Debt Comes Due

WannaCry (2017, MS17-010)

He used this as his first proof point: a known, patchable vulnerability, exploited at scale by organizations that had deferred the fix.

CitrixBleed (2023, CVE-2023-4966)

His second, more recent proof point: a disclosed vulnerability with a fix available before it was widely exploited, same pattern, different stack, years later.

His line connecting the two: different years, same root cause, a known gap left open long enough for someone else to find it first.

The Real Cost of Security Debt

Phước then shifted the talk from technical risk to business impact, breaking security debt into four categories of cost that leadership actually feels:

• Operational: inefficiency is usually the first visible sign, as workarounds and undocumented fixes pile up
• Financial: the cost of inaction doesn’t stay flat, it grows over time
• Reputational: the hardest debt to repay, especially when the cause was something already known
• Strategic: left unmanaged long enough, security debt eventually limits how fast and how confidently an organization can adapt and lead

That last point was where he pivoted the talk from problem to approach. Debt that never gets addressed, he said, doesn’t just sit there. It becomes a ceiling.

Replatforming: A Strategic Way Out

This is where Phước introduced how SupremeTech has actually been solving this for clients. He walked the room through AWS’s six common migration strategies, the “6 R’s”: Rehosting, Replatform, Retain, Repurchasing, Refactoring or Re-architecting, and Retire. Each has its place. But for organizations carrying real security debt, he made a clear case for Replatform in particular, done differently than usual.

A standard lift and shift cloud migration, he explained, is built around minimal change. Move the workload, keep everything else the same, solve a hosting problem. It does not solve a security problem.

Lift, Shift, and Hardening, the approach his team built, is deliberately not that. It’s Replatform combined with a security-first approach: instead of moving resources as-is on a routine legacy system migration, the move itself becomes the opportunity to optimize infrastructure and upgrade application versions, resolving the debt instead of relocating it.

Read related articles:

• Online MySQL Schema Migration Safely On Production with gh-ost – Testing On On-premise Database
• How to Harden AWS security group outbound rules with VPC Flow Logs, Athena, and AWS Bedrock
• Rollback Aurora MySQL’s Major Version Upgrade When Delta Data Already Exists
• Troubleshooting ALB mTLS with GMO CA Bundle

What Hardening Actually Delivers

He didn’t leave this as an abstract pitch. He broke the approach down into four concrete objectives, each with specific deliverables his team has actually implemented for clients:

Security Posture

Strengthening cloud security posture meant, in his walkthrough: migrate to a multi-account architecture with proper governance, implement encryption in transit and at rest, establish network security hardening and segmentation, deploy a modern IAM model, remediate critical and high severity vulnerabilities, implement defense-in-depth architecture, and establish security monitoring and incident response.

Infrastructure Modernization

Implement infrastructure as code for consistent deployments, establish automated security compliance monitoring, build a backup and restore strategy, and implement performance and cost monitoring.

Application Modernization

Update applications to the latest patched versions, update third-party dependencies to close known vulnerabilities, and establish secure configuration processes that follow best practice.

Operational Excellence

His framing for this one: the combined result of the three areas above, a system that isn’t just patched once, but structured to stay patched, monitored, and cost-efficient, rather than sliding back into the same debt cycle.

The 6-Phase Execution Roadmap

Phước closed the technical portion of the talk with the six-phase process his team follows on every engagement, structured deliberately so the security foundation is in place before anything else moves:

1. Assessment: understand the current system and where the debt actually sits
2. Foundation establishment: implement the security baseline everything else builds on
3. Infrastructure modernization: apply the infrastructure and security enhancements
4. Application security upgrades: remediate vulnerabilities and update to supported versions
5. Data migration: move the data once the destination environment is already hardened
6. Validation, optimization, and operational handover: confirm the goals were met, then hand the environment over

He was direct about the sequencing: skip the foundation phase to move faster, and the migration reintroduces the exact risk it was meant to remove.

FAQs Section