advanced 2 min answer

A multi-product SaaS company has accumulated overlapping internal systems - three notification services, four job schedulers, two feature-flag systems. How should rationalisation be approached?

freshworksrationalisationportfolioconsolidationmigration
Show the full answer Hide the answer

Why they accumulated

Each was locally rational. A team needed something, the existing option did not fit or was not discoverable, and building took less time than negotiating. Duplication is a symptom of the platform being harder to adopt than to bypass, not of poor discipline.

That matters because it determines the approach: consolidating without addressing the adoption barrier produces the same duplication again within eighteen months.

The approach

  1. Inventory honestly, including the ones nobody admits to. Usage telemetry finds them; a survey does not.
  2. Assess against real requirements, not against features. Which of the four schedulers actually satisfies the union of what the teams need — and which teams have requirements the others do not, since those are the reason four exist.
  3. Choose one, and be explicit that the choice is partly arbitrary. Where two are comparable, the tie-break should be operational maturity and the strength of the owning team, not a feature comparison.
  4. Make the chosen one better than the alternatives for the teams that must migrate, which usually means building the two or three capabilities that caused the divergence.
  5. Fund the migration. A rationalisation that asks teams to absorb the migration cost from their own capacity will not happen, and this is the step that most often kills the programme.
  6. Close the door, so new instances cannot be created — otherwise you consolidate four into one and get a fifth.

What determines whether it succeeds

Whether the migration is cheaper for the migrating team than staying. That is achieved by tooling, automated migration, dedicated support, and — decisively — by the surviving system being genuinely better.

A mandate without those produces compliance theatre: teams migrate the minimum, keep the old system for what the new one cannot do, and the estate now has both.

What to leave alone

Duplication that is cheap to run and expensive to consolidate. Two feature-flag systems where one is used by a single team on a stable product may cost less to leave than to migrate. Rationalisation is an investment with a return, and some instances have none — the discipline is to say so rather than to pursue uniformity for its own sake.