You’re an ISV. As sure as day follows night, someone is coming to eat your lunch, or at least try to.

It could be one of your competitors who is maybe more agile because they haven’t had such an aggressive M&A strategy and, as a consequence, haven’t had to subsume so many different products and technology stacks; or maybe a new market entrant (such as Workday in Higher Ed) who isn’t encumbered with the history of customers and who can address the needs of where the market is going rather than where it has been. All of those features (or new channels such as mobile, or new consumption desires such as cloud) that your customers have been asking for over the past few years, well here comes the new market entrant with all of them built into their product.

Note that it is not just missing features etc that can cause the need to modernize the application, lack of support and security loopholes within the technology stack can be equally strong drivers.

Of course, this is not new to you.

But did you know that the path to a modernized application capable of competing in the modern market is nowhere near as complex as you may think and, indeed, is well-trodden as evidenced by TOTVS, MV Sistemas and Miami-Dade County on this blog?

Backing up for a second, there are 3 broad options when faced with a software product that has fallen behind the demands of customers and the market generally:

• Re-write the application
• Check to see if there are short term benefits to be achieved by wrapping the application in a connectivity layer (a la Mulesoft)
• Re-architect the application

Please leave me a comment below if you’re aware of a product of reasonable complexity (say >100K lines of code) that has been completely rewritten and delivered on time and on budget. My experience is of delay after delay with projects eventually abandoned and another path to modernization sought.

The “wrapping” approach is valid if connectivity is an issue, for example, to enable web/mobile deployment. Where the core functionality of the application needs to be enhanced, however, wrapping can only be a short term solution as the underlying code needs to be modified. This leads us to re-architecting the application although wrapping may still provide a short term bridge in offering customers benefits.

Re-architecting the application essentially relies on a technology platform to transform the application from its existing language and stack to a new (typically multi-tier) language and stack. How much of this can be done automatically and how much requires manual code completion depends on the state of the code in the original application, the source language itself and, above all, the quality of the underlying technology platform.

When selecting a partner to provide support with re-architecting your application, here are some questions/guidelines to help with your selection process:

1. Make sure you run a Proof of Concept that ensures the partner can deliver the solution you require.
2. Be aggressive with the complexity and timescales on that PoC and be prepared to pay of the work. Maybe run a quick and easy PoC for free first to weed out the weaker vendors and follow-up with a paid PoC for the two or three leading contenders.
3. Ask if enhancements can be included as part of the transformation process.
4. If yes, ask which of those enhancements can be built into the transformation process (i.e. are delivered as part of the automated transformation process).
5. As an example, making an application responsive is something that should easily be catered for within the transformation process.
6. Does your partner provide a risk assessment up-front (e.g. are they providing you reports on the interdependence of modules within the application and indicating modules that carry the most risk)?
7. Is your partner refactoring the code as part of the transformation process (i.e. are they identifying duplicate and dead code with a view to reducing the application footprint)?
8. If extensibility is a requirement, how is your partner going to enable you to support field modifications?
9. If accessibility is a requirement, how is your partner going to support or introduce accessibility into the modernized application?
10. If you have multiple products in different software languages in need of modernization, can your partner support all of your requirements and drive you towards a standard technology stack?
11. Can the product UI be customized for (human) language as part of the transformation process
12. Are you migrating the database too? Can your partner support the transformation work here too?
13. If you are modernizing both the application and the database at the same time, how does your partner manage that process and ensure QA demarcation between the application transformation and database migration?
14. Is your partner providing all of the service work to complete the project or is there scope for your team to participate as well?
15. If you have multiple modernization projects can your team complete some of them internally?

How you feel about these last two points depend on your own internal point of view. Having the option to split individual projects with your partner or complete projects 100% internally may be of cost benefit if resources are available to do the work. This is something that Morphis does routinely with Miami-Dade County but is also something that needs to be managed with a view to employee morale.