Migrating to the Cloud, rewriting or replatforming, pt 1
Consultancy on steroids first article.
The cloud, it is someone else computer and is easier than managing your infrastructure on premise, true, the scalability and manageable cost is the difference.
It is always the solution, no, if you have the time and money to host your infrastructure on premise, maintain it and pay for it and create a disaster recovery plan and pay people for working after hours when a system fail on weekends or at night.
Let us talk about the Legacy applications, any company that had some kind of software development have some to migrate.
The legacy app was done for a need maybe twenty years ago, then updated, then got more data, then –one day- it is outdated; became too expensive to be maintained, the security teams have opened some issues that cannot be fixed anymore, or simpler you want to get rid of his slowness and lack of a modern user experience.
It is not only Cobol that doesn’t have coders anymore, try to find a C++ coder in the west that is less than 40 years old, and I’ve some doubt also on java or c# ones.
The legacy applications are the backbone of many companies, the company cannot live without them but they are sluggish and unreliable.
It is the ideal scenario for a “replatforming” project to the cloud, what are the steps?
- Understanding what the legacy application does
Understanding does not mean that you have to transpose 1 to 1 the old legacy application to the new application, you have to understand what it does and why.
There are different scenarios
- The functions and the information data of the legacy applications are still be valid in the near future, probability around 40%.
- The data is needed but the functionality could be improved, probability 30%.
- The client want to have the same functionality and data in the new system, will of the client 100%, real need, usually, 30%.
Usually you will be in the C case, the client will be sure that will need the legacy application replatformed as is, no improvements needed, it is working like that since twenty years and everybody is happy…really?
So the first question must be “Why you want to replatform it if it is working really well? “ then you have to expect a fierce resistance and answers of that kind “yes is perfect” and you have to “deep dive” with questions like “Can you explain better why such feature works like that?” and so and so on.
It will not be an easy task, you need patience, business analysts and patience and you have to recreate a puzzle… where you don’t have all the pieces upfront.
In the real world, legacy, applications exists because there is not an alternative but could be improved or, in the best case, could be substituted with a modern platform.
2)Start from the data
There are two main philosophies on the migration, look at the value or look at the data, usually I start with the first but let explain also the other one, starting with the data.
The data will be one, or more, database, some excel imports, some data sources and plenty of other small things in between, yes the yearly update is still manual since 1995.
In fact starting with the data will seem like pretending to take a rifle from the bayonet, it will be painful, extremely painful and time consuming and boring.
You have to keep in mind the value and figure out what the data value is.
The hardest part will be finding, and explaining to the customer, let me put in a real story:
When you have to migrate a subscription form, that have been migrated from another previous legacy application thirty years ago, you can avoid putting the client signature on every page and could use some kind of single sign on/customer identity check to accept all the form pages automatically.
Next week for the second part.