Moving the Same Furniture vs. Buying New

Opening Scene

A family moving to a new home can bring every piece of existing furniture along essentially unchanged, or use the move as an opportunity to redesign the space entirely, replacing furniture that no longer fits the new home’s genuinely different layout and possibilities. Both are legitimate strategies, but they represent genuinely different levels of ambition and effort. Data platform migration presents this exact same strategic choice between rehosting and re-architecting.

In Plain English

Rehosting (“lift and shift”) moves existing systems and workloads largely unchanged onto the new platform, minimizing migration effort and risk but potentially missing out on capabilities the new platform actually offers. Re-architecting redesigns systems to take genuine advantage of the destination platform’s specific capabilities, offering meaningfully greater long-term benefit but requiring considerably more upfront effort, risk, and time.

The Old Way

Before this strategic choice was widely and deliberately articulated, migration strategy was sometimes chosen without explicitly weighing both options:

Migrations sometimes defaulted to rehosting without genuinely evaluating whether re-architecting would deliver meaningfully greater long-term value.
There wasn’t yet a well-established practice of explicitly weighing rehost-versus-rearchitect tradeoffs for each significant system being migrated.
Some migrations pursued ambitious re-architecture without fully accounting for the considerably greater effort, risk, and timeline that approach genuinely requires.

Choosing migration strategy without genuinely weighing this rehost-versus-rearchitect tradeoff is what deliberate strategic evaluation directly addresses.

What’s Changing (and Why AI Is the Reason)

Organizations increasingly evaluate rehost versus re-architect explicitly for each significant system, rather than applying one strategy uniformly across an entire migration.
This connects directly to the migration driver covered in Article 3, since a capability-gap-driven migration often specifically justifies the additional effort of re-architecting, while a cost- or end-of-life-driven migration might favor faster rehosting.
As destination platforms increasingly offer AI-specific capabilities unavailable on legacy systems, re-architecting has become an increasingly common, deliberate choice specifically for systems where accessing those new AI capabilities is the actual migration driver.

The Metaphor, Fully Extended

Moving Day	Data Platform Migration Concept
Bringing every piece of furniture along unchanged	Rehosting existing systems largely unchanged onto the new platform
Redesigning the space entirely for the new home’s possibilities	Re-architecting to take genuine advantage of new platform capabilities
Both legitimate, but genuinely different levels of ambition	Both legitimate, but genuinely different levels of effort and risk
A strategic choice worth making deliberately	A strategic choice worth making deliberately, system by system

For Beginners: What to Actually Do

Practice explaining, in your own words, the tradeoff between rehosting a system unchanged and re-architecting it to fit a new platform.
Learn to recognize that this choice can, and often should, vary system by system within a single migration.
Get comfortable with the idea that neither strategy is universally correct.

For Practitioners and Leaders: The Deeper Layer

Evaluate rehost versus re-architect explicitly for each significant system, rather than applying one uniform strategy.
Let the migration driver identified in Article 3 inform this evaluation, since capability gaps often specifically justify re-architecting.
Consider re-architecting specifically for systems where accessing new, destination-platform-specific AI capabilities is the actual underlying motivation.

Quick Recap

Rehosting moves systems largely unchanged; re-architecting redesigns them to leverage the new platform’s capabilities.
Rehosting minimizes effort and risk; re-architecting offers greater long-term benefit at greater upfront cost.
This choice should be evaluated deliberately, system by system, not applied uniformly.
New AI-specific platform capabilities have made re-architecting an increasingly common, deliberate choice.

Where This Fits in the Series

Article 14 covered the strategic choice between rehosting and re-architecting. Article 15 turns to a validation step that applies regardless of which strategy is chosen: testing the utilities before moving in.