Pre-mortem workshop before a rewrite or replatform

Why rewrite plans go wrong before coding starts

Most rewrite plans fail before anyone writes code. The team starts talking about the future system, so the conversation fills up with new screens, new services, and a cleaner stack. Meanwhile, the current product gets a shallow summary, even though its daily problems should shape the whole decision.

That gap leads to bad scope. People say the old system is "messy" or "slow," but they do not name which workflows break, which reports people rely on, or which ugly workaround still keeps money moving. If you skip that detail, the rewrite starts with guesses.

Leadership often approves the project too early. A roadmap looks neat in a meeting, especially when the rewrite promises faster delivery, lower maintenance, or a fresh start. Then support joins later and points out the parts customers actually complain about, including edge cases nobody wrote into the plan.

Support data hides many of the risks. A ticket queue shows the weird cases that never make it into product docs: duplicate records, strange account states, old exports a few large customers still need, and billing flows that break only under specific timing. These details look small until the new system goes live and users hit them on day one.

Sales adds another source of trouble. A sales team may promise migration dates, missing features, or contract deadlines before engineering tests the real effort. Once those promises reach customers, the timeline stops being a plan and turns into pressure.

The room matters too. Product sees opportunity. Engineering sees technical debt. Support sees repeated pain. Sales sees revenue risk. If only two of those views shape the decision, the blind spots get expensive fast.

That is why a pre-mortem workshop matters before a go or no-go rewrite decision. It gives each team space to name failure paths early, while changing scope is still cheap and saying "no" is still possible.

What a pre-mortem workshop actually does

A pre-mortem workshop asks the team to do something most rewrite plans avoid: assume the project has already failed.

Picture it six or nine months later. The budget ran over. Customers got annoyed. Sales could not explain the change. Support tickets piled up. Engineering still had half the old system running. Then ask one question: "What went wrong?"

That shift changes the conversation. People speak more honestly when they do not have to defend the plan. They stop selling the rewrite to each other and start naming the ways it can break.

This usually brings up problems that stay hidden in normal planning meetings. Product may worry that the new version drops workflows heavy users depend on. Support may see a wave of migration pain. Sales may expect a freeze in roadmap promises. Engineering may spot missing dependencies, bad estimates, or a risky cutover path.

It also slows down rewrite infatuation. Teams often fall for the clean story: fresh code, fewer hacks, faster delivery later. That story can be true. It is rarely the whole story. The workshop makes people say the ugly parts out loud before months of effort lock them in.

By the end, you want a visible list of failure stories the team can test, rank, and act on. Most of them fall into a few groups: customer risk, revenue risk, migration risk, delivery risk, and ownership gaps.

The point is not to predict every problem. The point is to turn vague worries into clear statements such as "customers will lose feature X and churn" or "the team cannot run old and new systems at the same time." Once a risk is concrete, the team can test it, price it, or decide the rewrite should wait.

That is what the exercise does best. It replaces rewrite optimism with evidence.

Who should be in the room

A small group works better than a crowded call. You want the people who see risk from different angles, not a meeting full of observers.

For most teams, five to seven people is enough. In a smaller company, one person may cover two roles. That is fine, as long as each viewpoint still shows up.

Product should send the person who owns priorities and scope. They know which parts of the current product customers use every day, what cannot slip, and what the rewrite is supposed to fix.

Support should send someone who reads real complaints, not a manager working from summaries. They know which bugs users tolerate, which issues trigger refunds, and which awkward workflows people rely on anyway.

Sales needs to join because revenue risk hides in details. A rewrite can delay deals, break promised features, or confuse buyers who expect the current workflow.

Engineering should include a lead who knows dependencies, data moves, integrations, and the ugly parts of the current system. That person can spot migration work that never appears in a neat roadmap.

You also need one person who can make a call when the group gets stuck. If nobody in the room can say yes, no, or not yet, the session turns into a debate club.

If you can, pick a separate note-taker. The workshop moves fast, and people often mention the real risk only once, in plain language, before moving on.

Do not invite only senior titles. The person closest to the work often gives the bluntest answer. In this kind of session, that answer is often the one you need most.

What to prepare before the session

A pre-mortem works best when the room reacts to facts, not guesses. Start with one plain sentence that explains why the rewrite exists. If the sentence is fuzzy, the plan is fuzzy too.

Make it specific. "We are rewriting the billing system so pricing changes stop taking two weeks" is useful. "We want a modern platform" tells nobody what success looks like.

Bring recent evidence from the people who deal with customers every day. Support should show common ticket themes, the workarounds agents use, and the cases they dread because nobody can fix them cleanly. Those details often reveal the parts of the old system that look ugly but still keep the business moving.

Sales and customer success should bring hard dates: renewals, contract promises, launch commitments, and any deal that depends on a feature surviving the move. A rewrite can miss its target by a month very easily. If that slip would block a renewal or delay a promised rollout, write it down before the meeting starts.

Engineering and operations should arrive with a plain inventory of what the current product touches. Keep it simple: outside integrations, scheduled reports people rely on, manual steps staff still do every week, admin tools nobody talks about but everyone uses, and the parts of cutover that fail if timing slips.

This inventory helps teams avoid a common mistake. They plan the new product around visible features, then forget the quiet work around it: exports for finance, a custom webhook for one large customer, or a support-only screen used to correct bad data.

One more thing belongs in the prep notes: the cost of delay. Ask each team, "What breaks if cutover happens one month late?" You want concrete answers, not drama. Maybe support handles double volume. Maybe sales has to explain another missed date. Maybe finance runs a manual reconciliation again.

Put all of this on one shared page before the session. Skip the glossy deck. A messy page with real risks is better than polished slides with no friction.

How to run the workshop step by step

Start with a tight frame. Put the goal on the screen, name what the team plans to rewrite or replace, and state the date everyone is working toward. If the group cannot agree on scope and timing in two minutes, stop there and fix that first.

Then shift into the pre-mortem. Ask people to imagine it is six months after launch, the project is live, and it went badly. Revenue dropped, support tickets piled up, the team missed deadlines, or customers left because a workflow broke. That picture helps people stop defending the plan and start looking for weak spots.

A simple flow is enough:

1. Give everyone 10 to 15 minutes of quiet time to write failure paths on their own.
2. Go around the room and read every note out loud. Capture each one where everyone can see it.
3. Group similar notes together.
4. Ask which risks are most likely, most costly, or hardest to recover from.
5. Assign an owner, a next step, and a pause trigger for each serious risk.

Keep the wording plain and specific. "Migration will be hard" is too vague. "Billing sync will fail for legacy accounts created before 2021" is something the team can actually test.

Questions each team should answer

A pre-mortem gets useful fast when each team answers concrete questions. Vague worries do not help much. Specific failure stories do.

Start with product. Ask where users will notice the rewrite first, and what change will feel broken even if the new system works as designed. Small shifts in login flow, search results, billing screens, or saved settings can trigger a wave of complaints before anyone talks about architecture.

Support usually knows the messy truth. They see the edge cases, the half-broken records, and the strange customer habits that never made it into a spec. Ask which problems agents fix by hand today, because those manual fixes often disappear in a rewrite and come back as angry tickets.

Sales sees risk from a different angle. Some deals depend on current workflows, reports, permissions, or contract promises that look minor to engineers. If a buyer expects a certain export, approval path, or admin control, losing it for even a few weeks can cost real revenue.

Engineering needs to name the parts most likely to break under pressure. That includes data migration, third-party integrations, background jobs, cutover timing, rollback plans, and anything nobody has touched in years. If the team cannot explain how they will move data safely or reverse the launch, that is a warning.

A few questions work especially well:

• Where will users feel the change first, and what will they call broken on day one?
• Which odd cases do agents fix manually today, and what happens if those fixes vanish?
• Which active deals rely on the current workflow, even if it seems old or clumsy?
• Which data moves, integrations, or launch steps can fail in a way that is hard to undo?
• What exact signal would make the team stop and call for a pause?

That last question is often the most honest one in the room. "Pause" should mean something clear: error rates spike, customer data goes missing, billing syncs fail, support volume doubles, or a large deal gets blocked.

If people struggle to answer, that tells you something too. It usually means the rewrite is moving faster than the team's understanding of the current product.

A simple example from a real planning situation

A mid-sized SaaS company planned to replace its old customer portal. The portal looked dated, and the product team felt boxed in by old front-end code. They wanted a cleaner design and a setup that let them ship changes faster.

On paper, the rewrite looked sensible. The team expected better usability, fewer support tickets, and less time spent patching old code. They were close to approving months of work.

Then they ran a pre-mortem.

Support changed the tone first. They explained that a small but steady group of customers used the portal in ways nobody had written down. Some accounts had unusual billing histories, half-completed migrations, or old permission settings that only showed up after years of upgrades. The portal handled those odd states badly, but it still handled them. A fresh build might drop them by accident.

Sales added another problem. One large prospect was close to signing, but only if the company could provide a specific report inside the portal. That report did not exist in the rewrite plan. The team could spend six months rebuilding the portal and still miss the feature that mattered most to revenue.

Engineering then found the hardest issue. The old portal pulled data from tables and services that had grown over time with plenty of exceptions. The new data model looked tidy, but it did not map cleanly to real customer records. Migrating everything at once would force risky data fixes in the middle of the project.

The company did not cancel the idea forever. They trimmed the scope, delayed the full portal rewrite, and split the work into smaller parts. First, they added the report sales needed, documented the messy account states support saw every week, and cleaned up the worst data problems. Only after that did a narrower portal update make sense.

That decision likely saved them from a very expensive mess.

Mistakes that ruin the exercise

A pre-mortem breaks down fast when one confident person fills the board. Sales may dominate with customer stories, or engineering may drown the room in technical detail. This gets worse on small teams, where one founder or lead engineer can set the tone in five minutes. Start with silent writing before open discussion so everyone brings risks, not just the loudest voice.

Teams also ruin the session when they jump to fixes too early. The moment people start arguing about tools, architecture, or timelines, they stop naming the ways the rewrite can fail. Keep the first half focused on one prompt: "It is six months later, and this project went badly. What happened?"

Another common problem is mixing failure paths with wishlist items. "Better reporting" is a wish. "Reporting gaps hide churn during migration, so revenue drops before anyone notices" is a failure path. Push every vague point until it names a real loss, delay, or customer problem.

Unknowns get waved away too easily. If nobody measured how many customers use old workflows, how much custom support the legacy system needs, or how long data cleanup will take, that is not a small issue. It is a risk with missing evidence. Treat unmeasured areas as risky by default.

Do not end with a full board and no follow-through. Every serious risk needs an owner, a next action, a due date, and a rule for when the team pauses or rethinks the rewrite. Without that, the meeting becomes a neat ritual that changes nothing.

The room should leave a little uncomfortable, but much clearer about whether to proceed.

Quick checks before you approve the rewrite

Approval should wait until the room can answer one plain question: who gets hurt first if this goes badly? If nobody can name the first users to feel pain, the plan is still too abstract. A rewrite usually breaks something small before it breaks something obvious, and those early cracks often show up in the accounts that use odd workflows every day.

Before approval, make sure the team can answer a few basic checks with short, testable statements. Product should be able to name the user groups most likely to notice missing behavior, slower steps, or changed screens in the first week. Support should have a real list of edge cases, manual fixes, and strange customer habits that never made it into formal docs. Sales should have flagged live deals, renewal dates, contract promises, and demos that depend on features the new system might delay. Engineering should have mapped outside dependencies, migration steps, rollback options, and cutover risks. The group should also agree on pause triggers, such as failed migration tests, missing parity for top workflows, or too many open support issues before release.

If even one of those stays vague, pause approval. Vague answers usually mean people are still talking about the rewrite as an idea, not as a change that will hit real users, revenue, and operations.

One step gets missed all the time: someone needs to turn the notes into a go or no-go memo. Not a huge document. One or two pages is enough. It should name the risks, assumptions, pause triggers, the owner for each problem, and the reason to proceed now instead of later.

That memo matters because workshop energy fades fast. A week later, people remember the optimistic parts and forget the warnings. Writing it down forces a real decision. If the memo reads like a list of unknowns with no owners, you already have your answer: do not approve the rewrite yet.

What to do after the workshop

The workshop should change the plan. If the team walks out with the same scope, the same timeline, and the same risks, the session did not do its job.

Start by cutting work that failed the risk test. Keep the parts that protect revenue, support load, and customer experience. Move the rest to a later phase. If login migration, billing, and reporting all look risky, do not rewrite all three at once. A smaller release with a clear fallback plan is usually safer.

Then turn every open risk into a short task with an owner and a deadline. Do not leave a risk as "we will figure it out later." If the team is unsure about data migration, run a migration trial on a copy of real data. If they doubt AI test coverage, try it on one service for a week and measure defects, review time, and noise.

A short written follow-up keeps everyone honest. Note what the team removed from the first release. Turn unknowns into experiments, small trials, or customer checks. Put a review date on the calendar before anyone starts a long build. If the first experiments fail, stop and reassess.

That review date matters. Two weeks of proof can save two months of waste.

If the room cannot agree on the risks, bring in a neutral technical lead. An outside view helps when product wants speed, engineering wants safety, and sales wants every promise kept at once. For teams that need that kind of review, Oleg Sotnikov at oleg.is works as a fractional CTO and startup advisor. A short outside pass on scope, architecture, and rollout risk can make the go or no-go decision much clearer before months of work are locked in.