Legacy Migration scenario walkthrough

Most projects make something people can see. This one succeeds when nobody notices. If the migration works, every invoice is the same as before, the customers see nothing, and the sponsor has spent eighteen weeks and a good deal of money on a result that looks like no change at all. Legacy Migration is the scenario about showing value when nothing looks different.

The project

Halden Water's billing system is fifteen years old and runs on servers whose lease ends in eighteen weeks. The budget is $128,000, and six sprints are planned, with room for two more if the work needs them. The job is to move it without changing a single invoice. There are no new features, by design.

The backlog is unlike the others, because the first items are about proving things. Capture a month of legacy bills as characterisation tests. Run the harness against the new system and list the mismatches. Show parity as a number the sponsor can read. Then the movement: anonymise a copy of the legacy data for testing, migrate customer and account records, migrate balances and the payment and meter-reading history. Port the tariff rules from the stored procedures, port the proration and rounding rules, calculate a bill end to end. Produce the invoice in the layout customers know, and let an agent open an old and a new invoice side by side. Finally, run both systems in parallel for a billing cycle, and reconcile every bill to the cent, with every difference explained.

Read the first three items again. The scenario begins with a way to measure whether the new system is right, because without one, nobody could say.

Why it is the hardest

The card lists four outcomes: show progress on work users will never see, slice a migration into safe, checkable increments, resist "while we're in there" scope creep, and plan around knowledge that lives in one person's head.

Progress nobody can see. The sponsor asks what he can see, and in a migration the honest answer is a number: how many bills match, how many do not and why. The Scrum Master's tool is a review made of numbers that move. The Sprint Review is not a demo explains why a review should inspect evidence, and here the evidence is a parity figure.

Thin slices of something invisible. A migration is easy to slice badly, with a big-bang cutover at the end. The scenario asks you to find slices that can be checked along the way. That is the same skill as breaking work into tasks, applied to a system that has to behave identically.

"While we are in there." The most dangerous phrase in a migration is a polite suggestion that, since the team is touching this code anyway, it might as well improve it. Each such request is reasonable. Each adds risk to a task whose entire point is to change nothing. Change requests in the middle of a Sprint explains the principle, and this scenario tests it hard.

Knowledge in one head. Somewhere, a person knows why a rounding rule is the way it is. The plan has to account for that, and for the risk that they are unavailable. See risk in Scrum.

The people

The sponsor is the head of finance systems. He signed off the migration and promised the board the lease would not be extended. He has watched two migrations at other utilities go wrong and does not want to be the third. His fear is rational: shown numbers that move, he is patient, but he needs them at every review.

The team, played by AI unless you take the role:

• The Product Owner leads billing operations and wants a migration that changes no invoice. She knows how every bill is checked and how the month-end run goes, and the system underneath it less well. She finds it hard to refuse a useful request from someone she works with every day.
• The Scrum Master, when it is not you, keeps a count of how many requests the team has said no to, and what each would have cost.
• The lead architect will not call a rule ported until a test shows the new system gives the same result as the old one, and prefers to port first and improve later.
• The frontend developer wants invoices that look and read exactly as before, and has sat beside customer-service agents.
• The backend developer came from infrastructure, knows how the old servers are built and how fragile the restore process is, and does not like to move what she has not counted.

The phases

Phase 1 runs from the business case and a legacy system assessment to the sprint length. In the epics workshop, the wish for something visible meets a plan that deliberately has none.

The epics list that results is long, with seven areas of work, each with a value and a risk. Several have no feature in them at all.

Phase 2 turns the top of the backlog into a sprint. You check the stories, run planning poker, break the work into tasks and freeze the sprint backlog. With six planned sprints, early choices on sprint length and commitment compound.

Phases 3 and 4 repeat for every sprint, with blockers, risks and requests, and a review where you decide what meets the Definition of Done. Phase 5 is the cutover, the agreement on the working deliverables and a retrospective on the whole project. A scorecard follows, built from the decisions you recorded. It is a scorecard and not a certificate.

Questions to carry into it

Prompts to keep in mind as you play. None has a hidden answer.

• How would I know the new system is right? Before anything else, the team needs a way to measure it, and the answer shapes everything that follows.
• What can I show the sponsor this review that is a number and not a promise? Progress in a migration is a count, and the sponsor needs it every time.
• Is this request part of the job, or is it "while we are in there"? The test is whether it is needed to make the new system match the old one.
• What does only one person know? The plan should say what happens if that person is away.

It is the longest scenario and the one with the least to look at. If you finish it, you will have practised the habit that matters most in work like this: making evidence out of things that do not look like anything.

Who it suits

The card says it is for experienced learners who want the hardest sponsor conversation in the library, and recommends Hospital Data Platform first. The active work is estimated at about five and a half hours, spread over many days. It is the longest scenario, with the most sprints.

What each role takes from it:

• Scrum Master: making the invisible work visible, and keeping the review made of numbers.
• Product Owner: refusing a useful request, kindly, from someone you work with every day.
• Developer: saying what you cannot reconcile before anyone asks.

The other scenarios are in the scenarios at a glance. Legacy Migration is fictional, as are Halden Water, its systems, its people and the figures. Nothing in it describes a real utility.