Have a project moving on to a higher plane? Make a plan to prevent getting stuck in limbo.

As technology innovators, we get excited about ushering in new ideas and implementing new technologies. Sometimes, however, we might overlook the less flashy labor needed to retire old ideas and replace existing software. Those ideas and software may still be operating perfectly according to their original specifications, but the world has moved on around them, and they need some help to transition their users as well as the software to newer implementations. We also often are tempted to overlook the human side of this work, which means convincing the people who have been happily using this technology to accomplish their own work that there are advantages to be gained by redoing their workflows and projects. 

One example of this we’ve experienced recently in the research group is migrating projects that were implemented years ago with VMs on OpenStack to a new, more flexible container infrastructure with Red Hat OpenShift and OpenShift Virtualization. Infrastructure providers can clearly see the scaling and support advantages to using containerization in large datacenters, but the advantages may be less clear to an individual project owner. In some ways, the human side of a project migration requires many of the same steps we follow for making a will. 

Choose executors

Determine who you trust to make high-level changes to your project in order to be able to support it in the new infrastructure. This may also mean retiring some parts of your workflow that are no longer needed (great!) or reimplementing parts that require some change (oh no!) to still accomplish your project goals. The people you trust with this duty will be your executors. You cannot lead your project and also be your own executor, because you probably don’t have the objectivity or the detailed knowledge to watch over all the different aspects of the transition. 

For example, a small database that was OK to run on a VM for your project may need to move to a different, more scalable database. Although this will require a migration effort, in the end your project data can grow faster, making it easier for you to collaborate with more researchers. At Red Hat Research, we often work directly with project leaders on tasks like this to help speed a transition, but sometimes the right person is an internal university programmer or an open source contributor who worked on the earlier versions of the project. The important thing is to ask the right people to evaluate where changes are needed, and let the rest of the team involved in the transition know who the executors are before the transition starts.

Choose inheritors

Determine what you want to keep in the project and what you want to give away. Projects that run for years can collect features like barnacles. Every once in a while, a thorough scraping is needed to keep the project team moving efficiently. That one feature that was added a few years ago for a single collaborator who has since retired may not be necessary anymore. Look over your project’s functions and workflows and decide what is still productive and essential. Name a person to inherit responsibility to watch over the transition or retirement of each function and workflow. These are the people who will ensure that the retained functions continue to operate as needed when the project migrates. 

Sometimes the function has nothing to do with the actual software changes, for example the function of communicating to the rest of the scientific community what you are doing with your project. It is important that the people you choose to inherit your important functions are people familiar with the project who also appreciate the value of the function they are caring for through the migration. Sometimes these people are representing an entire community for large projects, and sometimes they are individual developers who developed their modules on the original project with you. In either case, it is important that they are named specifically. If the migration is done right, they will become beneficiaries of the process.

Have witnesses

Sign your project transition plan in front of witnesses. Okay, you don’t need a notary public for this, but everyone involved in the project—the people on the infrastructure team and other teams supporting any transition—must be able to agree on a written description of how the project is changing and who is responsible for verifying that the project is working successfully and as expected after the transition. At Red Hat Research, we find that developers, SQA, and User Experience engineers are often extremely good at specifying what “successful” means for parts of a transition plan, but remember that other specialties can be needed here. For example, your project may have privacy or compliance requirements that require legal review for a migration.

Inform all beneficiaries

Make sure you notify anyone who is affected by the project transition before it starts—in other words, before the reading of your project will. This includes giving your users adequate time to prepare for a transition, of course, but may also include less obvious things like your Identity Provider or the IT staff who bill for your services. When in doubt, overcommunicate, because overlooking an impact of your project transition, even if it is not part of the core function, can delay and complicate it. That uncle who didn’t know he was inheriting your stuffed weasel collection may not be pleased, just like that person who was going to run a workshop with your project on the day it is down for transition maintenance.

Make it findable

Keep your transition plan in a place that the entire team can easily access, and make sure to notify everyone of the location periodically. You know best whether this is a Google Doc, a repository, or a shared folder on your department server, depending on your team. Make sure that you don’t send out just one email when the first draft is finished and then stuff the plan in a drawer in your grandfather’s roll-up desk.

Update as needed

If that uncle who was getting the weasel taxidermy passes away, or your database developer decides to take a new job, you need to promptly update the plan to show the changes succinctly. Then notify everyone involved that the project plan has been updated (again).

Following these suggestions can help you prepare your project for a successful transition from the earthly plane to a new life in containerized nirvana. More importantly, it can help the people who work with you and those who depend on your project for research, education, and development enjoy moving their workloads to a faster, more flexible environment—one that they could find heavenly as well.