Replatform or Fix Forward? Making the Right Call When Things Aren’t Working

[shazza72]

Executive Summary

Organisations inevitably reach moments where their core platforms are no longer delivering the outcomes they expect. Performance degrades, upgrades become risky, user experience fragments, and technical debt accumulates. At this crossroads, leaders are faced with a fundamental decision: fix what is broken while moving forward, or replatform entirely and start again.

This white paper explores how to make that decision deliberately. Using a practical, real‑world analogy and proven architecture principles, it provides a framework for choosing between Fix Forward and Replatform approaches with balancing risk, cost, continuity, and long‑term value. The intent is not to advocate a single answer, but to enable the right answer for each organization. One size does not fit all.

1. The Problem: When the Platform Isn’t Working

Most platforms do not fail suddenly. Instead, they degrade over time through well‑intentioned customisations, urgent fixes, and incremental design decisions made without a long‑term blueprint. Common symptoms include:

• Increasing effort to deliver simple changes
• Upgrades that require extensive remediation
• Inconsistent user experiences across processes
• Data models that no longer align with out‑of‑box capabilities
• Growing reliance on tribal knowledge

These symptoms are well documented in ServiceNow replatforming guidance, where accumulated technical debt and customisation complexity are cited as key drivers for reconsidering platform strategy .

At this point, the question is not whether to act but how.

2. The Analogy: Broken Tiles in the Entryway

Consider a house with cracked tiles in the entryway. I am currently facing this issue. 😩

• If only a few tiles are broken, and the subfloor is solid, you replace the damaged tiles.
• If tiles keep cracking, matching tiles are no longer available, and the floor beneath is uneven, you stop patching and retile properly.

Enterprise platforms behave the same way. Some issues are cosmetic or localised. Others indicate deeper structural problems. Architecture’s role is to determine which situation you are in before more effort is invested in the wrong response.

3. Fix Forward: Repairing While Moving Ahead

Fix Forward (sometimes called “fix in place”) focuses on correcting issues incrementally while continuing to operate on the existing platform.

When Fix Forward Makes Sense

Fix Forward is appropriate when:

• The core data model is fundamentally sound
• Customisations are manageable and well understood
• The platform can still upgrade and adopt roadmap features
• Disruption must be minimised

This approach is commonly used where continuity of service is critical. For example, fix‑forward programs often allow capabilities to continue evolving while foundational improvements such as data model alignment are introduced in parallel .

Benefits

• Lower immediate disruption
• Reduced change fatigue for users
• Faster time to incremental value

Risks

• Prolonged inconsistency in user experience
• Delayed realisation of full platform benefits
• Risk of accumulating new technical debt if standards are not enforced

Without a clear design plan, fix forward can devolve into architectural patchwork where each local fix makes sense in isolation, but collectively results in a fragmented and inconsistent platform. Much like replacing a few cracked tiles and discovering the colours or patterns no longer quite match, teams often find themselves extending repairs beyond the original area simply to restore visual and operational coherence.

4. Replatform: Retiling the Floor

Replatforming involves deploying a new instance or implementation, typically returning closer to out‑of‑box standards and modern architecture patterns.

When Replatforming Makes Sense

Replatforming is justified when:

• Core processes require redesign that the current platform cannot support
• Customisations materially block upgrades or roadmap adoption
• Data models are fundamentally misaligned with platform standards
• Long‑term strategic change is already planned

Industry guidance highlights replatforming as an opportunity not just to reset, but to modernise, eliminating technical debt and positioning the platform for future innovation.

Benefits

• Clean alignment to platform standards
• Improved upgradeability and supportability
• Consistent user experience by design

Risks

• Higher short‑term cost and disruption
• Organisational change and retraining
• Loss of legacy behaviours users may value

Replatforming is not a technical exercise alone, it is a business transformation.

5. The Missing Ingredient: The Tile Pattern (Reference Architecture)

Whether fixing forward or replatforming, success depends on having a clear pattern to work toward.

In a house, you would never replace tiles without knowing:

• Tile size and orientation
• Color and finish
• Grout style and spacing

In platform terms, this pattern is your reference architecture defining:

• Data model standards
• UX and experience principles
• Integration and customization guardrails
• Governance and lifecycle practices

Architecture blueprints and replatforming templates exist specifically to create this shared understanding and prevent fragmented outcomes.

Without this, fix forward creates inconsistency, and replatforming risks recreating old mistakes in a new environment.

6. A Practical Decision Framework

Leaders can simplify the decision with three core questions:

1. Is the subfloor sound?

(Foundational data, security, integrations, governance)

• If yes → Fix Forward is viable
• If no → Replatforming should be considered

2. Can we match the tiles?

(Standards alignment, UX consistency, roadmap fit)

• If yes → Fix Forward with strong guardrails
• If no → Replatform or staged rebuild

3. Are more renovations planned?

(Future capabilities, scale, mergers, regulatory change)

• If no → Tactical remediation may suffice
• If yes → Design once, build once

Staged replatform approaches explicitly accept short‑term inconsistency in order to achieve a clearly defined end state .

7. Conclusion

Fix Forward and Replatform are not competing ideologies, they are tools. Architecture’s responsibility is to apply the right tool at the right time, grounded in evidence rather than urgency.

Fixing broken tiles works when the floor is still level and the pattern still exists. Replatforming is necessary when the subfloor is cracked and the pattern has been lost.

Making the right call requires honesty about the current state, clarity about the future state, and discipline in execution. A key warning sign is the emergence of patchwork where repeated local fixes begin to sprawl across the platform, driven less by strategy and more by the need to make adjacent areas "match." Patchwork often indicates that an organization is already paying the cost of replatforming incrementally, but without the benefits of a clean design or cohesive end state. With the right intent and governance, however, these moments of platform frustration can be redirected into opportunities for lasting improvement.

This paper is intended to support executive decision‑making and architecture governance discussions. It should be read as guidance, not prescription, and applied in the context of each organisation’s risk tolerance, strategic priorities, and operational constraints.