A technology overhaul involves the replacement of major sections of the current code or redesigning the product's architecture, while keeping the functionality of the code roughly the same. A new technology may be required to solve systematic design flaws. Consider an overhaul in response to major issues that cannot be fixed gradually along with new development.
The need for an overhaul can often occur on a legacy system you inherited. On the other hand, an overhaul can be a nightmare for a development manager who supervised building the system in the first place. In either case, explain to your boss and peers why the choices were made in the first place and why significant changes need to be made now.
Time and resources are always scarce in small companies, so competition for them can be intense. If you don't get peer and management buy-in, dealing with expensive problems that are not easily visible and do not produce short-term visible results can result in misunderstandings and mistrust.
Also consider the impact of an overhaul on your customers. These changes might (and often do) force changes in the customer's operations or technology. For example, your changes might require that the customer purchase a new third-party application, such as database software. You must consider the customer impact before starting the work and offer your customers sufficient notice of upcoming changes.
How the overhaul is handled depends on the projected cost and business needs. If the overhaul is "minor" and development can complete it in a single focused release over a three- to six-month period, implementing the changes at once makes the most sense. It will require the support of marketing and sales, because a release that does not improve the product features can cause problems with sales growth. You will need a strong business case for performing a technology overhaul, as doing so will displace other important product work.
If the changes are not minor and cannot fit into a single short-term cycle, your choices are more difficult. A one- to two-year overhaul project rarely makes business sense for a small company. It leaves the company's product features static for too long. The time delay of the overhaul invites a large amount of risk from competition and from loss of momentum with existing and future customers.
One approach for an overhaul is to map out the effort by major sections per release. This can be difficult to coordinate along with normal releases and will drag out the effort over a longer time if additional staff is not available. Another approach is to build the new system in parallel with work supporting the existing system. This can be logically simpler but requires extra staff and infrastructure that you may need to scale back at the end of the effort.
In summary, when you believe a technology overhaul is needed, you must create and present a clear business case for it and continue to push the issue toward resolution. Don't wait until the system blows up and hurts your product and customers.