While according to Merriam-Webster “legacy” is described as “relating to, or being a previous or outdated computer system” and Wikipedia adds “yet still in use”, I feel like we software developers and especially software architects are too hastily in naming a system or sub-system legacy. From a high-level architecture point of view, which spans across a whole year or even longer, it can indeed make sense to mark some systems as legacy, while planning out the next steps to introduce new systems in place of the old ones. The problematic part in my eyes comes in, when the first step of a migration to a new system is to rename the old system “legacy”.
We all know that plans never get executed according to the plan, but that things will change, requirements and urgency will shift. As such, if you’ve just renamed or labeled the current system as legacy system, but then have to change your focus onto the next topic, you’ve done everyone a disservice. Now you’ve created a “legacy” system that developers aren’t motivated to extend or clean up, the business doesn’t want to invest into it, all while the system still has to be maintained. The label change didn’t obsolete the system itself, but it set up new expectations for said system.
If you can follow through with your plan, this might be the effect you’re looking for, i.e. stop the investment into the old system and free up resources for the development of the new one. However, if things aren’t going according to plan, you’re left with a forever-active “legacy” system.
My plea to software architects is to know how to communicate on a given level. If you tell a user that their system is legacy and that there might one day be a replacement, you only cause frustration in the user. But if you trying to get more support from business, it might be a good idea to present the plans of having the legacy system fade out. On a developer or code level, I propose to only start naming things legacy, once you’ve already started to implement the new system. At this point you have the requirements and the budget to at least start with the new system, thus there’s a good chance that even if the project temporarily halts, it can eventually be carried forward. Additionally, the “legacy” part is fully justified, because you do have a new system (in development) and thus the old system becomes legacy.
To summarize: Don’t name systems legacy before you’ve even started replacing the said system.