So your business has a software system or software project that needs some attention.

Maybe there is pressure or need to replace the software system  altogether.

The reasons for replacement or update can be varied. Maybe it’s scalability, security, usability, or features. It could even be due to maintenance issues or a business need to change the architecture.

Whatever the reasons behind it, you have a decision to make about how to move a software system to a better place.

How do you decide what level of investment / work to do?

1. You can keep the software you have

Remodel or refactor the software

Refactoring is a way to make incremental changes or add iterative improvements to a body of software over time without replacing what you have.

Refactoring software is like repairing a boat as you sail across the lake. You make small changes so as to keep the boat afloat and not sink it.

By refactoring you keep the usage, benefits and revenue of the existing system but iteratively improve what you have. In most cases, it’s lower risk and can be less disruptive and lower cost.

An adroit team of developers can identify and iteratively improve an existing system surprisingly quickly. This mechanism can breathe new life into existing code in less time, with lower risk and a far more predictable schedule that the full replacement options listed below.

Depending on the level of need and the root issues this may be a viable option. However, you the situation warrants it, you may have to replace.

2. You have to replace the software you have

At one large company I was at years ago, our VP was known for responding to requests for software development resources for new projects with the following paraphrased response: “First we steal, then we buy, then we build”.

By his response, he was showing the truism regarding internal software development economics.

Reuse is cheaper than buying.

Buying is usually cheaper than building and maintaining.

If for business or functional or support reasons you have to completely replace what you have, there are essentially three options.

Steal

This is a metaphor for reusing software from another project or system within your company. It’s also called creative re-use.

If you have multiple projects or programs, one may have the software foundations already in place for what you need. Reusing or repurposing that can take less total effort and risk than standard replacement methods.

Buy

At this time in software development history, there are commercial options for almost every business need. It is worth it to look at your requirements and scan the existing universe of commercial software to see if there is an existing fit. This method can reduce time to market or reduce time to reap the benefits of having the system.

Build

Nothing exists that you can use for the need you have.  Or maybe what exists so prohibitively expensive or not a fit for your needs. If you don’t have anything laying around to reuse and you can’t use what is available on the 3rd party market, you must build it.

If you have to build it there are a lot of considerations to make.

• Internal vs external team
• Tech Stack to use
• Specific external libraries or 3rd party services to use
• Architecture
• Development Environment
• Deployment Environment
• Non-Development Resources

If you decide to build the software internally also consider the ongoing maintenance costs after initial release that will be associated with hosting, updates, training, security patches, environment, and feature improvements.

So What

By considering all the available options a business has regarding software replacement, including re-factoring, an owner or sponsor improves the odds of the best decision for the company.