The first meeting after a rebuild decision tends to open with the same question. "Do we start over from scratch?" Underneath the question is a real worry: that everything built so far gets erased and the team starts again on a blank page.
The most common way into a rebuild is hitting the stop signals covered in the third part while improving the current product.
Fortunately, a rebuild is not a blank page. Most of what you've built carries straight into the next version. What needs setting first is the line between what to bring forward and what you can leave behind.
What to Carry Over, What to Leave Behind
"Rebuild" usually conjures an image of wiping the repository and starting over from an empty editor. In practice, what you can actually leave behind is narrower: the code, the screens, and the structure tying them together. Everything else carries into the next version.
- Users: User accounts carry the relationship built up over time. Login credentials, org membership, and permissions are the values that define who uses this service.
- Data: Behavioral records and transaction history carry over as well. What users have already done stays a valid asset even after the structure changes.
- What you learned: The validated flow, the features you tried and cut, and the request log all carry forward. These are records of which sequence reduced drop-off, which features got shelved, and what users asked for again and again.
The easiest of these to lose track of is the validated flow. What was validated is the sequence, not the screen. You can redraw the screen, but the order it carried out still has to hold.
It is not unusual for a subscription service to lose this distinction. Data already confirms that one confirmation screen right before checkout was cutting cancellations. During the rebuild, the design team strips that screen out for a cleaner look. Cancellations climb right back up once the confirmation step disappears. The screen can change, but the job it was doing has to carry over regardless.
Two Common Mistakes
Two mistakes recur across rebuilds.
First, changing what was already validated. Starting a rebuild hands the team a rare chance to work on a blank page, and that chance is tempting to treat as an opportunity for a rebrand. It reaches past a new logo and a tighter name into flows that had already tested well. The problem is that touching validated and unvalidated parts without telling them apart removes any way to trace the cause once the new version underperforms. There's no longer a way to tell whether the drop came from the new structure or from disturbing a flow that had already proven itself.
Second, putting back everything the MVP cut. Building the MVP meant cutting features to fit a fixed budget and timeline. A rebuild looks like an excuse to pull that list back out and restore it item by item. Treat 2.0 as a finished product, though, and the same problem the MVP had comes right back. Of the features you cut, bring back only the ones tied to whichever of the three questions, core data, user type, or core flow, shifted the most. The rest can wait for a later cycle. The second version is still a scoping decision, same as the first one was.
Running Both Versions in Parallel
Shipping the rebuilt version does not mean retiring the existing one on the spot. The two need to run side by side for a stretch.
- How long to keep the existing version running: Keep it running until the new version covers every core flow the existing one handled. Any flow still unvalidated in the new version means the users who depend on it need the existing version kept open.
- Who moves to the new version first: New users go first, since they carry no expectations about the existing flow and friction is lower. Invite existing users once stability holds, then cut everyone across at the end.
- Data migration: Don't move it all at once. Pick one version as the source of truth and keep the flow one-directional, or nobody can say with confidence which copy is current.
Communicating the Transition
During the parallel-run period, what to tell existing users and when needs its own plan.
What to say first is not the list of what's changing, but the list of what isn't. Confirm that login credentials carry over, that accumulated data stays intact, and that pricing holds. That's where a user's first worry lands the moment they hear about a rebuild. What's actually changing comes after.
Timing matters too. Notify before the release ships, follow up individually as users get migrated, and afterward confirm there's a path back if something breaks. Send one announcement and stop there, and the same question keeps coming back through support for the whole parallel-run period.
Timeline and Budget
A rebuild's timeline and budget don't get measured against the MVP's yardstick.
It can run shorter, since the hypotheses that needed validating at the MVP stage are already validated, cutting down the time spent deciding what to build.
It can also run longer, stretched by migration and the parallel-run period. Most teams wrap that within two or three cycles, but the volume of data to migrate and the complexity of the flows involved can shift the window considerably.
Check whether a quote folds migration and the parallel run into the general development line items or breaks them out on their own. Folded in, there's no way to confirm later how much time and cost that work actually took.
Whichever path you take, improving or rebuilding, the second cycle of putting a product into the world and keeping it running brings on an entirely different set of problems. The fifth part covers live deployment control, feedback screening, and re-estimating the budget.
Why Integrabbit Budgets Migration and Parallel Operation as Separate Line Items
Integrabbit prices data migration and parallel operation as line items separate from development in a rebuild quote. Neither shows up as a new feature on screen, so folded into the general estimate, they stay invisible at the quoting stage and come back midway through the project as "we didn't know this would take this much work."
Scoping the volume of data to migrate, the expected length of the parallel run, and how users move from the existing version to the new one at the quoting stage means any growth mid-project is visible against the original budget. How long to run the parallel period, and how much of this to fold into the current rebuild, stays the client organization's call.
Previous: If You're Improving: How Far to Take It and When to Stop
Next: What You Face Either Way: The Shared Work of a Second Cycle
If you're heading into a rebuild and can't tell what to carry forward and what to leave behind, a 30-minute consultation can help map out where things stand.