Transformation Archetypes: Why You Need to Know What Kind of Project You Are Running
- Kenneth Linnebjerg
- 11 minutes ago
- 8 min read
Today Everything Is Called a Transformation
Look across a large enterprise transformation portfolio and you may see a strange thing.
One initiative is replacing a thirty-year-old application.
Another is moving an existing application onto a cloud platform.
A third is introducing a standard SaaS product.
A fourth is building an integration platform that other programs depend on.
A fifth is trying to create a completely new digital capability.
Yet they may all pass through the same governance process.
Same business-case template.
Same steering committee.
Same roadmap.
Same status reporting.
Same milestones.
Same expectations about scope, cost, schedule, and value.
We have standardized how transformations are governed without first asking whether the work itself is the same. It isn't. And that matters more than it initially appears.
What Kind of Transformation Are You In?
Technology already has useful language for distinguishing different modernization strategies. Martin Fowler defines refactoring as changing the internal structure of software without changing its observable behaviour. [1] Cloud migration frameworks distinguish approaches such as rehost, replatform, refactor or rearchitect, rebuild, replace, retain, and retire. [2][3] These distinctions matter technically.
But enterprise transformation needs to go one step further. We need to understand the transformation archetype: the dominant structural nature of the change we are trying to create. Why? Because different transformation types contain different uncertainty, different risks and different mechanisms for creating value. That means they should not always be governed through the same assumptions.
Refactoring: Improve the Structure Without Changing the Behaviour
A refactoring transformation deliberately preserves most existing behaviour while improving what sits underneath it. Perhaps the application is difficult to maintain. Perhaps the architecture does not scale. Perhaps technical debt makes every future change expensive.
The transformation is creating value, but much of that value may be invisible to the user.
That immediately creates a governance problem.
If management measures progress mainly through new functionality, a successful refactoring effort can look unproductive.
The important evidence is different:
Has the behaviour remained stable?
Has maintainability improved?
Has technical complexity been reduced?
Can future change move more easily?
The mistake is not poor reporting. The mistake is applying the success criteria of feature development to work whose purpose is structural improvement.
Replatforming: Preserve the Capability, Change the Foundation
Replatforming looks similar from a business perspective. The user may see almost no change. Underneath, however, the transformation may affect infrastructure, runtime environments, identity, security, networking, databases, monitoring, interfaces, deployment, and operations.
Microsoft, AWS and Google explicitly distinguish replatforming from both simple migration and deeper refactoring. [2][3] The key uncertainty is often not: What should the system do?
That may already be quite well understood.
The uncertainty lies in whether the existing capability will behave correctly on the new foundation. The important governance questions therefore concern compatibility, technical dependencies, performance, security, operational readiness, migration, rollback, and cutover. A roadmap dominated by feature completion can easily hide those risks.
Replacement: The New System Exists — But Can the Old One Disappear?
Replacement is structurally different again. The old solution is expected to go away.
That sounds simple until the organization discovers what the old system actually contains.
Legacy systems are rarely just software. Over years they accumulate rules, workarounds, interfaces, local adaptations, manual processes, data dependencies, special cases, and knowledge that may no longer exist anywhere else.
The dangerous assumption is that replacement means rebuilding what is already there.
But transformation usually requires two decisions:
What must be preserved?
and
What should deliberately not be preserved?
This is why replacement contains much more discovery than it often receives credit for.
It is also why a replacement is not finished merely because the new application is live.
If important users, processes, data, integrations, or business capabilities still depend on the old platform, the replacement is structurally incomplete.
The strongest evidence of progress is therefore not simply construction of the new system.
It is the progressive transfer of capability away from the old one. Incremental replacement patterns such as Martin Fowler's Strangler Fig approach address precisely this risk by progressively moving capability rather than relying entirely on one large cutover. [4]
Standard Solutions: Are We Changing the System or the Organization?
Now consider an ERP, CRM, HR, procurement, planning, or service-management implementation. This may also replace an existing system. But it contains a different tension. The organization selected a standard product because somebody concluded that buying standard capability was preferable to building everything from scratch.
Then requirements begin. Users explain what the existing process does.
Local organizations describe why their version is different. Interfaces are requested.
Exceptions emerge. Customization starts.
Soon the transformation faces a fundamental decision again and again:
Should the system change, or should the organization change?
That is not merely a requirements question. It determines the shape of the entire transformation. Every deviation from the standard can create consequences for configuration, extensions, testing, integrations, maintenance, upgrades, training, support, and future change. Governance therefore needs to control deviation deliberately.
Without that structural discipline, a program can spend millions buying a standard platform and then progressively reconstruct the complexity it intended to remove.
Enabling Transformations: Value Appears Somewhere Else
Some of the most important transformation work produces very little visible value by itself.
Consider an API platform. A cloud foundation. An identity capability. A common data platform. A development platform. A reusable integration service.
Their purpose is to enable other transformation. This creates another measurement trap.
Measure them purely through direct business benefit and they may look weak. Measure them purely through technical completion and teams can build impressive platforms nobody actually uses.
The important question is different:
What can move now that could not move before?
An enabling transformation creates value by changing the conditions for downstream flow.
The platform matters because five application teams no longer need to solve the same integration problem independently. The data foundation matters because several business capabilities can now use trusted data. The identity service matters because another part of the transformation can move through a previously blocked dependency. Its real output is not infrastructure. It is enabled transformation flow.
New Capability: Delivery Cannot Start With Certainty You Do Not Have
Finally, some transformations attempt to create a capability the organization has never possessed before. There may be no existing system to copy.
No established process. No reliable understanding of user behaviour. Perhaps even the business model is partly uncertain. This changes the meaning of progress.
Detailed planning cannot remove uncertainty that only experimentation, design, prototyping, testing, and real-world use can remove. Yet organizations frequently govern this work as if implementation has already begun. The business case becomes precise.
The roadmap becomes detailed. Milestones become commitments. Scope becomes a baseline.
The system creates an appearance of predictability by converting assumptions into dates.
The real early work should instead reduce uncertainty.
Leadership should ask:
What do we still not know?
Which assumption matters most?
What evidence would justify the next commitment?
Learning is not something that happens before the "real work." For this archetype, learning is part of the real work.
Misclassification Creates the Wrong Governance
This is where transformation archetypes become practically important. Imagine what happens when we classify the work incorrectly.
A refactoring initiative is treated as feature development, so teams are rewarded for visible functionality instead of structural improvement.
A replacement is treated as straightforward requirements refinement, so the organization assumes it already understands what must be replaced.
A standard-product implementation is treated as custom development, so every existing behaviour becomes a candidate requirement.
An enabling platform is measured as an independent technology project, even if downstream teams still cannot use it.
A new capability is managed as predictable implementation even though the fundamental uncertainty has not yet been resolved.
The result will eventually appear in conventional project language:
delay.
scope growth.
cost increase.
rework.
dependency problems.
slow decisions.
missed milestones.
But those may be downstream symptoms. The earlier error was structural. We applied the wrong control logic because we misunderstood the type of transformation we were asking the organization to perform.
Large Programs Contain Several Transformation Archetypes at Once
There is another complication. Real transformation programs are mixtures. A large application modernization initiative may replace one legacy platform, replatform another, refactor shared components, implement a SaaS product, create a new API platform, introduce new digital capabilities, and eventually retire several obsolete applications.
Even a single application can contain different modernization strategies at different layers. Google has documented exactly this kind of mixed migration behaviour. [5]
So the archetype should not necessarily be attached to the program. It should be attached to the work. And that classification can change as knowledge improves.
What began as a replatform may reveal architectural limitations requiring refactoring.
What appeared to be a straightforward replacement may reveal an opportunity to use standard functionality instead.
A supposedly new capability may turn out to duplicate something already hidden elsewhere in the enterprise landscape. The archetype is therefore not just a label. It is a structural hypothesis that should remain visible throughout the transformation.
Progress Depends on What Kind of Work You Are Doing
This leads to a simple but important conclusion. We cannot define progress independently of the transformation type.
For refactoring, progress is improved structure with preserved required behaviour.
For replatforming, it is successful transition and operational readiness on the new foundation.
For replacement, it is transfer of required capability and removal of dependency on the legacy solution.
For standard-product implementation, it is adoption of the target capability while keeping deviations intentional.
For enabling transformation, it is demonstrated downstream usability.
For new capability, progress includes removing important uncertainty before committing further.
This does not mean creating six different transformation methodologies. It means recognizing that the same methodology is processing different kinds of work. Agile does not make those differences disappear.
Project management does not make them disappear. Architecture governance does not make them disappear. SAFe does not make them disappear. The structure still exists underneath the method.
Before Asking Whether It Is on Track, Ask What It Is
Most transformation portfolio reporting starts with questions such as:
Are we on schedule?
Are we within budget?
Is scope stable?
What is the RAG status?
Those questions have value.
But another question needs to come first:
What kind of transformation are we actually in?
Because only after answering that can we decide what uncertainty matters, what evidence constitutes progress, where value should appear, what transition must be controlled, and which risks deserve leadership attention.
The purpose of transformation archetypes is not taxonomy for its own sake.
It is to stop fundamentally different kinds of work from disappearing behind the generic word transformation.
Transformation work needs to be governed according to its actual structure.
If we misunderstand the structure, better execution of the wrong governance model will not solve the problem.
References
Martin Fowler — Definition of Refactoring
Why it matters: Fowler provides a precise definition of refactoring as restructuring software while preserving its observable behaviour. This distinction is essential when separating structural improvement from functional replacement.
Amazon Web Services — About the migration strategies
Why it matters: AWS distinguishes seven migration strategies, including rehost, replatform, refactor, repurchase, retain, retire, and relocate, illustrating why different modernization paths should not be treated as equivalent work.
Microsoft — Select your cloud migration strategies
Why it matters: Microsoft's Cloud Adoption Framework explicitly differentiates migration and modernization approaches including replatform, refactor, rearchitect, rebuild, and replace, reinforcing the importance of deliberate transformation classification.
Martin Fowler — Strangler Fig Application
Why it matters: The Strangler Fig pattern demonstrates how replacement can be managed incrementally, progressively transferring capability from a legacy solution rather than relying entirely on a high-risk single cutover.
Google Cloud — Real-world cloud migration strategies
Why it matters: Google describes how different layers of the same application can require different migration strategies, supporting the broader argument that one program — or even one system — may contain several transformation archetypes.
Comments