Big-bang rewrite

A big-bang rewrite replaces an entire application with a new one built from scratch and moves all users over in a single cutover.

In a big-bang rewrite the team builds a complete replacement in parallel with the existing application. The old one stays in production until the new one is ready. Then, on a chosen date, everyone moves. Users receive nothing from the new system before that date.

The appeal is clear: a clean start, a modern stack and no bridge code between old and new. For a small application with stable requirements it can be the right choice.

Example

A company decides to rewrite its AngularJS product, with well over a hundred screens, in modern Angular. The estimate is twelve months. During that year the old product still needs fixes and new features, because customers do not wait. Each of those changes has to be built twice or added to the rewrite backlog, so the target keeps moving. The cutover date arrives with some screens missing and some behaviors that nobody remembered to copy. The first real user feedback comes all at once.

Common misunderstanding

The usual assumption is that a rewrite is faster because the team is free of the legacy code. That code also contains years of business rules, edge cases and fixes that are documented nowhere else. Rediscovering them takes a large part of the time.

The other hidden cost is concentrated risk. All the value and all the defects land on the same day, and going back is hard once data has moved.

Before choosing this route, check the size of the application, whether the business can freeze features, and whether a route-by-route alternative exists. The guide Rewrite, hybrid or micro-frontends compares the options.

Related terms

• Incremental migration
• Strangler fig pattern
• Rollback