Legacy Support and Forked Systems

As Projects evolve and Business Systems receive new versions, there are times when a Project may not be able to upgrade immediately, or may require behaviour that diverges from the mainline System implementation. To support these scenarios, IMSF defines clear processes for legacy support and forked systems.

This page outlines when legacy support applies, how forks are created and maintained, and what the long-term implications are for Partners and the Systems Library.

What Is Legacy Support?

Legacy support refers to maintaining older versions of Business Systems so that Projects depending on them can continue to operate safely, even if newer versions introduce breaking changes. Because IMSF uses pinned versions, a Project will never be forced to upgrade.

Legacy support ensures:

• older versions remain accessible and installable
• critical security fixes can be backported if necessary
• Projects have extended time before adopting breaking changes
• Partners experience no disruption during transitions

Legacy support preserves stability for long-term Projects, especially Partners with sensitive workflows or regulatory constraints.

When Legacy Support Is Used

Not every Project upgrades at the same pace. Legacy versions remain available when:

• a Project relies on deprecated workflow behaviour
• a major feature overhaul is incompatible with an older workflow
• a Partner requires extended validation cycles
• the Project uses a customised workflow that depends on old behaviour
• the cost of upgrading outweighs the benefit for the Partner

These scenarios are normal as the Systems Library grows in capability and complexity.

What Is a Forked System?

A forked system is a copy of a Business System that diverges from the mainline version. This is used only when a Project requires behaviour that cannot be supported within the standard System without breaking compatibility for others.

Forks are rare and should be created intentionally, with clear documentation, because they require ongoing maintenance.

A system fork is appropriate when:

• a Partner requires permanently custom logic the mainline cannot support
• a global breaking change cannot apply to a specific Project
• a heavily modified workflow contradicts new underlying behaviours
• branching the system is cheaper than rewriting workflow logic

Forked Systems vs Pinned Versions

A pinned version is simply an older version of an official System. A forked system is a modified System that diverges from the core.

Pinned Version

• receives occasional security or stability patches
• remains identical to the historical version in the Systems Library
• is fully upgradeable later

Forked System

• is its own independent System, not bound to mainline updates
• may introduce Project-specific logic
• does not automatically track improvements from the core System
• requires its own versioning and documentation

Forks are a tool of last resort because they introduce parallel code paths that must be maintained separately.

How Forked Systems Are Created

The Innopo Platform provides a structured workflow for creating a fork to ensure clarity, maintainability, and accountability.

The fork workflow:

1. Identify the specific behaviour that cannot be supported upstream.
2. Duplicate the System as a new package (e.g. quote-engine-fork-staffmate/).
3. Apply changes in isolation.
4. Document differences in a Fork Notes file.
5. Version the fork independently using semantic versioning.
6. Pin the fork to the Project requiring it.

Systems that are forked must clearly indicate:

• their origin version
• the reason for divergence
• the Partner(s) depending on the fork
• whether reintegration into the mainline is possible later

Maintaining Forked Systems

Forks introduce long-term maintenance considerations. Because they do not automatically receive updates from the Systems Library, the Innopo team must manually decide whether to:

• backport improvements
• patch vulnerabilities
• fix bugs discovered after divergence
• eventually reintegrate features into the mainline System

A fork should always have a clearly defined purpose and be evaluated periodically to determine whether it can be retired or merged.

When Forks Should Be Avoided

Forks increase maintenance cost, so IMSF encourages using:

• workflow layer overrides
• feature flags
• optional configuration hooks
• custom UI injected at the Project layer

These tools can typically support Partner-specific variations without modifying a System’s internal logic, preserving the ability to stay on the mainline.

Sunsetting Forked Systems

Where possible, Projects should eventually transition off a fork and back to an official Business System. This occurs when:

• new features make the fork redundant
• a major version redesign removes the original conflict
• the Partner’s workflow evolves to match mainline behaviour

Sunset plans help reduce technical debt and unify the Systems Library.

Summary

Legacy support and forked systems ensure long-term stability across all Projects while allowing Partners to adopt new functionality at their own pace. Legacy versions offer safe, predictable behaviour when upgrades are not immediately feasible, while forks provide a controlled escape hatch for unique Partner needs that cannot be supported upstream.

Both mechanisms work together to give IMSF the flexibility to support diverse workflows without compromising the modular integrity of the Systems Library.