Software Switching and Migration Checklist

0 / 17 completed

Decide

• Write down the three problems the current tool fails to solve and how you will know the new one solves them
• List every active user, their role and how often they actually use the current tool
• Check the current contract for renewal date, notice period and early-termination terms
• Collect written quotes from at least two alternatives for the same seat count and billing term

Evaluate

• Ask each vendor for security documentation such as a SOC 2 report, data retention policy and model-training policy
• Confirm which export formats the current and new tools support, and test an export before committing
• Run a two-week pilot with a small group using real work, not demo data
• Verify that the integrations you rely on exist natively or through a maintained connector

Migrate

• Take a full backup of documents, notes, templates and automations before changing anything
• Map old folders, tags and permissions to the new structure in a simple spreadsheet
• Migrate one team first, fix issues, then move the rest in waves
• Rebuild automations and integrations in the new tool and test each with sample data

Roll out

• Hold a short training session and publish a one-page guide with approved use cases
• Set up single sign-on or enforce strong passwords and multi-factor authentication for every account

Retire

• Keep the old tool in read-only mode for 30 to 60 days in case something was missed
• Cancel the old subscription in writing before the notice deadline and export final invoices
• Review cost, usage and satisfaction after 90 days and record what you would do differently