No platform lasts forever. Every platform has an end-of-life. Ideally, developers decide to move their application another platform long before that happens. They may maintain two variants for a while, but will stop supporting the old platform when most users have moved to the new one.
Sometimes, a platform’s end-of-life comes suddenly. For years, Microsoft assured developers that it would continue to develop and support the FoxPro platform, but day before yesterday Microsoft decided to kill the FoxPro platform (see Microsoft kills FoxPro).
Developers with their application still build on top of a platform being retired need to deal with this. They need to consider their options and make a few tough choices.
The most obvious option is to migrate to another platform, but it is not the only one. There are three main scenarios, three basic approaches towards this issue: quit the business, stick with the platform anyway, or migrate to something new.
Some organisation may decide that the challenge is just too much, that they do not have the resources to continue to compete now this has happened, and get out of the business. When that happens, user groups will continue to support the application for some time, but few new users will pick it up. Eventually, all users will have moved on to a competing product.
The exodus of users presents a unique opportunity for competing vendors to grow their user base. Turn that idea upside down; a developer that quits could do worse than contact close competitors about a possible buy-out, complete with a migration program for existing customers.
Some vendors will stick with the platform. Some will do so because they are not aware of the issue, some because they see no other choice, some because they believe in the platform and hope for a revival.
Although the overall outlook for such vendors may be bleak, a few that offer unique features may find themselves a good niche. They certainly put less pressure on users; by not abandoning their users. As the platform grows stale, users will abandon them, but by continuing to develop and support their product, its unique features may continue to attract users.
Migrating seems to most desirable option. The migrating process itself is not very desirable. Migrating is hard work and takes time and resources away from developing new features, but the result of migration - the application once again being on a well-supported current platform - is desirable.
Migration is a great option because you get to reconsider all choices, typically for the first time since the application’s inception, especially when the decision is to do a complete rewrite. A rewrite from scratch is a great moment to redesign the application and adopt new development techniques. It is the perfect opportunity to apply any lessons learned. It is a great moment to get rid of mistakes you would not have made if you knew back then what you know now.
These three basic approaches are the extremes, and the best approach may well be somewhere in between.
It may be possible to do a partial or phased migration. For example, perhaps it is possible to create another client for a server, so that each user can migrate the clients at their own pace. Perhaps a server can support both the old and a new protocol, and support both for several versions, before the old one is retired. Perhaps it is possible to migrate the application without changing the data format of its files.
Perhaps you should stick with the old platform for a particular clientele, or quit only part of the business to concentrate on another part.
Spending some time picking the right approach is worth it. Possible benefits are that there is less to do, that it is less disruptive, more manageable and easier to test.
The opportunity to redo everything makes migration an attractive option. Over time, applications are often extended far beyond their original design, and a new design that actually fits its current purpose and feature set would simplify the code. An additional benefit is that a new platform will generally provide ready-made, built-in support for features you used to code yourself, and thus allow further reduction and simplification of application code.
Still, the approach is not without risks. It is possible for the redesign to be too ambitious, and extend far beyond the practical reality of the application. Learning a new platform and adopting new techniques takes time, and initial code is likely to be of throwaway quality. If such risks are not understood and managed, the result is likely to be a poorly performing, unreliable and incomplete application.
A tempting mistake is to consider all time spent migrating the application as lost time and try to hurry through it. Sure, competition may be developing new features, but every new feature they make is also a feature they will have to migrate one day. Their current technology and timetable may be different, but they will face the same issues.
Time spent migrating is not lost time. A rewrite creates the foundation for the next generation of releases. Done right, the application design is likely to be better and the code cleaner, providing a good basis to graft new features on, features that would be much harder to write and get right on top of the old code base. Do not hurry laying the foundation. Take the time necessary to do it right. Take time now, to save time later.
It is tempting to start creating the new application right away, but that is not wise. Accept that it takes time to learn the new platform, get familiar with new tools and techniques, and unlearn old habits. All those seniors on the old platform are juniors on the new platform. Give them some time to develop their platform skill to medior level. Let them get comfortable with the new platform by writing some utilities or trying different approaches to a single problem. Be ready to throw early code away simply because it below par. Consider hiring expert guidance for the new platform.
Another tempting mistake is eagerly embracing all kinds of new features enabled by the new platform. The ability to create exciting new features may be one of the reasons for migrating, but new features do not belongs in a migration project. The design should account for future features, provide the basis for it, but migration must focus on just one thing: get things working on the new platform. Doing new features at the same time practically ensures that the migration effort itself gets short-changed.
Maintain focus on the task at hand. Once you have decided to migrate to a new platform, do just that. Continuing providing patching for defect, but stop adding features to the old code. Do not add new features to the new code either. Migrating is hard enough already.
The organisation does not just need to decide how to move forward and do it, but also address user concerns by communicating their plan and their progress.
An organisation that migrates long before their current platform is retired can do so at their leisure, and then surprise the community with their new product. An organisation that migrates after the end-of-life has been announced, cannot afford the same amount of silence.
Users concerns should not be underestimated. Many users do understand that there is problem. They are naturally concerned about the future of the product they use, and like their concerns to be taken seriously. An organisation that merely informs the users that it has a plan is inviting a solid dose of scepticism and offending users by brushing off them off.
The development organisation cannot get away with merely saying that it has a plan. An organisation that merely claims it should be trusted to handle things will not garner the same amount of confidence that they really are on top of things as one that actually informs its customers about their progress.
Make their concerns your concerns. Communicate how you plan to address those concerns, and assure continuity. Do not just do so once, but release timely status updates.
Users that are kept in the dark will consider the uncertain future of the application a risk, and mitigate their risks by exploring their options. Informing users is not just a courtesy, it is necessary to keep them from switching to a competing product.
Copyright © Tamura Jones. All Rights reserved.