The lift n' shift

This is the continuation of "The script that refused to stay small".

The conversation had already been happening for months: three data centers, rising costs, aging hardware, and a growing sense that the whole setup was one incident away from becoming a liability.

The decision came quickly after the "kalima" event: everything had to move.

What followed was not elegant, as the platform team scrambled to pull off a lift & shift:

• hypervisor VMs mapped 1:1 into cloud instances
• network rules replicated (and occasionally guessed)
• storage reattached, sometimes awkwardly
• timelines optimistic, then revised, then ignored

Most applications... just came along for the ride whilst Marta watched all of this unfold.

Her service was, technically, just another VM in the inventory. It could have been copied over, like everything else, but the lift and shift was rushed and was accumulating tech debt almost by definition. So she made a different call.

Instead of following the 1:1 VM migration path, she opted into an early container platform the company had been experimenting with—something not yet standard, slightly under-documented, but good enough.

Not because she was trying to be innovative, but because her system made it easy.

Containerizing the application turned out to be almost trivial.

Quarkus already produced a lean runtime, with the TPF pipeline living inside a single process with well-defined boundaries. There were no hidden dependencies on the host, no fragile startup scripts, no tight coupling to the underlying machine.

Marta wrote a Dockerfile, wired a couple of environment variables, and that was… mostly it.

The hardest part wasn’t the application, but everything around it:

• getting the right network access
• aligning with security policies
• making sure it could talk to the same external systems as before

So while most systems were being translated from one VM to another, Marta’s was quietly being repackaged.

And once it ran, something became clear:

• It was still a monolith
• Steps still called each other directly, in-process
• The pipeline still lived entirely inside a single runtime

Only the execution environment had changed.

That was the first quiet lesson TPF taught the team: you can move where something runs without changing how it behaves.

A few weeks later, someone asked Marta how long her migration had taken; she hesitated (because the honest answer sounded wrong: “About a day. Maybe two, if you count the networking issues.”

Photo credit: Javier Mediavilla E, CC BY-SA 2.5 https://creativecommons.org/licenses/by-sa/2.5, via Wikimedia Commons