Legacy Capacity Released.

The challenge

Legacy products under contract. Capacity locked in.

The investor had recently acquired a large B2B SaaS platform carrying a significant portfolio of legacy products. Active SLAs meant these products had to be maintained for several more years, yet the investment team suspected they absorbed far more engineering capacity than their commercial contribution justified.

Management reporting could not answer the question with confidence. Team structures cut across products, and self-reported time allocation was unreliable. The investment team needed evidence from the code itself.

1. 01

   How much of the development workforce is attached to legacy products?

2. 02

   Which functional domains do legacy and core products share?

3. 03

   Where could legacy be merged into core, and how much capacity released without breaching SLAs?

The solution

One pass over the code. A full map of where capacity goes.

CodeDD's Development Activity analysis read every repository and its full commit history. No workshops, no self-reporting, no disruption to the engineering organisation.

1. 01

   Mapped the resources

   Every developer's contribution mapped against each application marked as legacy, a precise, code-evidenced view of the workforce attached to legacy maintenance.

2. 02

   Defined the domains

   Functional domains defined for every legacy application and matched against the core product, exposing where the two overlap.

3. 03

   Revealed cross-repository collaboration

   Shared domains showed where teams already work across legacy and core, the natural migration paths for people and functionality.

4. 04

   Quantified the release

   Capacity-freeing scenarios ranked by significance, sequenced against SLA commitments, the most material consolidations first.

The results

A defensible reallocation plan, in one week.

• 18% of development capacity attached to legacy systems identified for release to core growth products.

• Migration paths defined through shared domains: which teams and functionality move to core, from where, and in what order.

• SLA commitments protected a legacy maintenance floor sized from actual change activity, not headcount guesswork.

• First insights within 24 hours of repository access; full consolidation recommendations within one week.

• Every figure traceable to source code and commit history, evidence the board could act on.