A retailer of the kind Flipkart operates runs payroll on a 19-year-old mainframe application for 60000 employees across three countries. Every April a statutory change absorbs about four months of work from two of the three remaining developers who understand it. The portfolio review must assign a disposition. Which one?
Show the full answer Hide the answer
The deciding property
Not the age, not the mainframe, not the three remaining developers. It is that the capability is a commodity whose specification is written by someone else and changes every year. Payroll rules are set by tax authorities and published; every vendor in the market implements them for every customer at once. The retailer is paying two engineers to re-implement, in isolation, a change that a vendor amortises across thousands of customers.
Why repurchase
The recurring statutory change is an annuity of cost with no differentiating output. Eight engineer-months a year is roughly 0.7 FTE of permanent capacity committed to staying level, before any of the other work the system needs. A vendor absorbs that as part of a subscription, and the contract makes it their obligation rather than a dependency on two people.
Repurchase also solves the knowledge concentration, which the other options do not. Rehosting, replatforming and refactoring all keep the requirement to understand 19 years of accumulated payroll logic in-house, and that understanding is the scarcest thing in the picture.
Why the other options fail
- Rehost moves the hosting problem and leaves every other problem intact. In April the same two people implement the same change, on a cloud instance instead of a mainframe. It is the right answer when a data-centre exit deadline is the binding constraint and nothing else is.
- Replatform is tempting because it looks like progress for weeks of effort. It reduces operational toil and does nothing about the statutory treadmill, which is the actual cost driver.
- Refactor into services is the most expensive wrong answer here. It requires the deepest engagement with logic the organisation is trying to stop owning, from the people it cannot spare, for a capability where a bespoke result has no value over a bought one.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Payroll encodes genuinely unusual terms (collective agreements, shift premia, cross-border splits) that no product supports | Refactor or rebuild the exceptional part only | The commodity argument fails exactly where the rules are yours |
| A data-centre exit lands in seven months | Rehost first, repurchase after | Repurchase cannot be rushed; a lift is reversible and buys the runway |
| The system also does workforce scheduling that product teams depend on | Split before deciding | One disposition per capability, not per application |
What it costs
A payroll migration is 12 to 24 months of parallel running, a data cleanse nobody budgets for, and the loss of the ability to absorb an unusual request in a week. The organisation also accepts vendor dependency on a capability it cannot be without for a single cycle. Decide the exit terms, data export format and the parallel-run length before signing, because the day the old system is switched off is the day the negotiating position disappears.
Common weak answers
- "Rehost first and decide later." Defensible against a hosting deadline. Without one it spends a year and leaves every cost driver in place.
- "Payroll is core, so we must own it." Critical and differentiating are different claims. Payroll is critical and its rules are published by somebody else.
- "Our rules are too unusual to buy." Usually about 90% commodity and 10% genuinely local. Buy the 90% and keep the 10%, rather than owning all of it to protect a tenth.