There are a number of things the team will need to do during this period. The following diagram shows some possible stages with example activities for each:

We should first let our team know that change is on the horizon. If we already know where they will be moving on to, we can prepare them by involving them in the new team missions and membership discussions.

Next, our team will need to wrap up their current work, so it's ready to be handed over to its new owners.

We should take time to reflect and celebrate the team successes. We also need to record our learnings so that we may pass on the benefit of our experience to improve both ourselves and others. One recommended way to do this is in the form of a retrospective.

Depending on how long the team has been formed and working on its current piece of work, this could potentially be quite involved. The longer the engagement, the more time that will be needed. 

One of the most significant challenges with any retrospective is remembering what happened, particularly over such a length of time as two years. Even in a two-week iteration retrospective, people often say things like, "I can’t even remember what happened yesterday, let alone last week."

When setting up the retrospective, we need to start prompting team members' memories so that when they come to the retrospective, they can recount their collective experience. The simplest way to do this is to send out invites to the retrospective early enough that it will trigger some thought. 

I've also used tricks like asking the team to bring a souvenir from their time together. It could be anything from a printed piece of code to a desk ornament, anything that has significance and that holds/triggers a meaningful story.

Here's the full outline of a retrospective I ran for one team at the end of a long-running project: Project now departing at Gate 12: https://making.stuff.co.nz/project-now-departing-gate-12/.