In every business—and even in open-source projects—there comes a time when demand outgrows the status quo and the time for change arrives. In the rapidly evolving world of technology, this is all too relevant. Robert Kennedy stated, "Progress is a nice word. But change is its motivator. And change has its enemies." Unfortunately, it is sometimes necessary to take a step back to make way for progress, and this can make the process even more difficult. Human nature resists change, yet logically everyone knows it's necessary. The key is to make the process as smooth and painless as possible.

It's often obvious that a project needs to change. The question is really how to do it. Will the old project just be given a face-lift, or does it need to be thrown out completely to make way for something new? Will the new project be thrust upon the users, or will it be slowly fed to them over time? Retiring the old amid the flurry of a new release is quick, but sometimes a gentle approach is better because it gives users time to adapt and accept what's to come instead of forcing it upon them. In this case, incrementally migrating the new into the old is an effective approach. This is a common approach among software companies, providing users with upgrades and new features over time to allow users to learn and grow with the software. It generally means more initial work on the developers' end, but it aids customer retention.

To provide users with a project worthy of change, developers must first go back to the beginning: Take a look at how the project was initially constructed and evaluate if that is still the most effective and feasible option for current needs. In the case of a software application, this may mean reconsidering the programming language. What was it about that programming language in the first place that made it the best solution? Is it still viable? It may seem drastic to rewrite a program in an entirely different language, but it may be the only solution. If this is the case, be prepared for resistance. Backward compatibility will be compromised, and users won't like that, but if it really is the only solution, remain firm. Even if users are presented with change gradually, some will balk. Complainers will be vocal, so be prepared to respond. Make sure that decisions are well founded so a strong defense can be provided. It may not be a popular choice, and some users may leave, but if the right decision was made this will all be resolved in time. Most importantly, keep users informed: Be open, explain the need for change, and openly accept criticism and questions. Provide a road map so a clear goal is established and everyone understands where they are headed. Use every medium available to inform. Publish articles and blog entries, and make announcements on the company website well in advance to give users time to prepare.