Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Challenge of Application Rebuilds

DZone's Guide to

The Challenge of Application Rebuilds

Application rebuilds should be very rare, but when they need to happen, certain challenges always join in.

· DevOps Zone ·
Free Resource

Read why times series is the fastest growing database category.

Technology keeps moving forward.

apple-iphone-5-unboxing-20This is a fact.  It’s what underlies our global economy and much of our modern lives. So it’s easy to look at a software product, application, website, or mobile app and determine that it has outlived its usefulness because it was built a few years ago.  It is easy to go with the technology flow and decide to start over.

If you have reached this conclusion about your own product, you are considering an Application Rebuild.  The Application Rebuild is a challenging project and it is different than new development or feature work.  So, you should think about it differently.

For starters, with rebuilds there often isn’t an MVP (minimum viable product) except: “make it do everything the old product did, only better.”  Users often won’t accept a replacement that doesn’t have all the old features, and who can blame them?  None of us want something that is new but does less.

Here are some of the other challenges that this situation creates:

  • Hidden Features – features that were created long ago and are used only rarely or only by a small subset of users.
  • LOE Misunderstanding – when the original application is built over 5 or 10 years and in small stages, it is easy to underestimate how much work will go into recreating the entire thing.
  • Data Validation Testing – testing to confirm the new application does things just the way the old application did.
  • Application Cut-Over – the process/project of rolling out to users and switching over to the new application.

Embarking on a rebuild ‘just because’ or due to technology shifting over the years is seldom a good enough reason for the work, cost, and commitment required to rebuild.

Technology change can be a compelling business reason if the technology is unsupported and poses a business risk or if new technologies create a compelling business case with solid ROI.

Businesses specializing in these rebuilds will build safeguards and process steps for handling Application Rebuilds when it is truly the appropriate move.  They adopt changes to best practices for rebuilds that make them different than from-scratch, feature addition, or maintenance development.

Much of this has been a high-level overview. Developers know that there are some specific issues and particular pitfalls that they will encounter on a project to project basis.  If you have an application to rebuild, a product to reimagine, or a program whose usefulness may have outlasted the maintenance life-cycle of the underlying technologies, it is critical to have a strong plan before embarking on the path to rebuilding.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

Topics:
legacy applications ,application architecture ,application lifecycle management

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}