Handover Guidelines

Hero image for Handover Guidelines

Transferring Materials

When a project comes to an end, most of the materials are transferred to the client. Here is the guide to transferring the general materials created by Nimble and ensuring to keep a copy of all materials.


The Product Manager should export the .fig files and send them to the client. The client can import the files to their Figma workspace. Please note that the export file doesn’t include any comment or version history. (As exporting is often restricted for some users, the designer may need to be involved.)

Export .fig file

Notion (Product Documentation)

  • The client uses Notion: the Product Manager duplicates the product documentation page and moves the duplicate to the client’s workspace. The client needs to provide access to their workspace.

For more information about moving the content to another workspace, please visit Notion Help Center.

  • The client doesn’t use Notion: as the product documentation won’t be deleted, it can continue being shared with the client.


The team does not delete the Shortcut workspace after the project ends. The client can continue accessing it.

In order to keep the workspace clean, the Product Manager should downgrade the permission of the squad and client to the observer role.

Shortcut workspaces cannot be duplicated. If the client requests the workspace to be transferred to their organization, the process is the following:

  • Export the data to .csv and keep it in the shared client folder on Google Drive (for historical purposes).

For more information about exporting data, please visit Exporting Shortcut Data.

  • Request the link to the client’s Shortcut organization.
  • Contact the Shortcut Support Team via [email protected] to move the workspace to the client’s organization. The owners of both organizations need to be CCed in the email loop to confirm the migration. The support team will respond to the first request within 2 business days but the migration process will take just a few minutes after they get the owners’ confirmations. The migration can be scheduled if necessary.

Google Drive

  • The client uses Google Drive: the files should be duplicated and the duplicates should be moved to the shared folder provided by the client.

  • The client doesn’t use Google Drive: the client can download the shared files as a local copy. Sharing the entire project folder to the client to download is also possible. Before sharing the folder, the Product Manager needs to ensure that the folder is well organized and doesn’t contain an internal-use only file.


For the diagrams in Lucidchart, it is better to export each diagram as an image and attach it to the related feature document or GitHub Wiki.

If the client requests to have the editable file, the Product Manager can export it as Visio (.vxdx) for the client to import it into their own Lucidchart Workspace.


Only the credentials that the client needs will be transfered individually, not an entire 1Password vault for security reasons (e.g. to avoid mistakenly transferring other credentials).

How to share credentials securely

Handover Meeting

The handover meeting should take place at least 2 weeks before the project end date so that the Product Manager and the development team can have sufficient time to fulfill any missing or additional requests from the client.

  • Goal:
    • Understand the handover needs of the client
    • Point out where to find the product/technical documents
    • Solicit the client’s feedback and question on the existing documents, and also check if other topics need to be documented
    • Explain the process to transfer materials with the client
  • Duration: 30 minutes to 1 hour
  • Parties involved:
    • Business and technical stakeholders
    • Product Manager
    • Project Manager
    • Team Lead
    • Engineering Lead

Handover Email

Below is a generic email template that should be used as a foundation to formally notify the client about the end of the project:

Hi {stakeholders},

As discussed, the project will end {dddd, dd MMMM yyyy} (end of the day) as stated in the contract.

It was a pleasure working with you on {project scope}, and we hope you enjoyed working with us. 

As for the next steps:
- {dddd, dd MMMM yyyy}: {Handover Material #1 with explanations}
- {dddd, dd MMMM yyyy}: {Handover Material #2 with explanations}
- {dddd, dd MMMM yyyy}: I will archive all the Slack channels

Please let me know if I'm missing anything.

After the project is handed over, you're welcome to reach out to me by email if you need any support.

We're looking forward to working with you again!

Post-Handover Support

The Product Manager should define a clear post-handover communication plan for the client and remain helpful.

The project channels will be archived on the next day after the end of the project or the warranty period.

Before archiving the channels, the Product Manager should send a polite message to say goodbye and inform the client that they can still reach out to the Product Manager in case of need. (For the shared channels, the client will still have access to their side of the channels. So, it’s nice to end it with a positive note.)

After the project end, in case of need, the client can reach out to the Product Manager exclusively via email.

Here are some examples of what the Product Manager can do to support the client after the project ends:

    - Point the client to the right feature documentation, GitHub Wiki or service if they have a question.
    - Tell the client where to find Analytics or Products KPI if they want to figure out if a feature is still being used.
    - Write new documentation
    - Spec any new idea or feature
    - Investigate bugs (unless the project has a support agreement)
    - Get involved in meetings