Platform Migration
Part of Support technology improvement
Evaluating a new platform after a process review
Turn process-review findings into a keep, extend or replace decision, with requirements and transition work made visible.
Consider a new support platform when a process review identifies a material requirement the current setup cannot meet with acceptable effort or risk. Record that gap before comparing products. A replacement will not settle an unresolved decision about who owns a case or what counts as finished.
Turn findings into requirements
Separate findings into processes to clarify, configurations to repair and capabilities the current setup may lack. Tie each proposed capability to a customer or agent task. “Keep the customer's question and next owner visible after a handover” gives a vendor something concrete to address; “modern omnichannel experience” does not.
For each material gap, record the affected cases, current failure, minimum acceptable outcome and consequence of leaving it unresolved. Identify any manual step the team can accept. Use that record to judge whether improving the existing setup remains credible.
| Option | Evidence needed for the decision |
|---|---|
| Improve the current setup | The process or configuration change, its owner and a way to check the result |
| Add a limited capability | The cases it covers, data it needs and person maintaining the connection |
| Replace the platform | The requirements still unmet, transition work and a route for continuing active support |
This is a decision aid, not a requirement to exhaust every option. An urgent unsupported need may justify a faster replacement review when the reason is recorded.
Options for Addressing Identified Gaps in Support Platform
- Improve the current setupRequires a documented process or configuration change, clear ownership, and a method to verify results.
- Add a limited capabilityMust specify the cases covered, required data, and person responsible for maintaining the connection.
- Replace the platformOnly justified if requirements remain unmet after evaluation; requires transition work and ongoing support continuity.
Ask vendors about the identified gaps
Give candidates the same short requirements brief and ask which proposed plan or edition is being offered. Request a written response distinguishing native capability, configuration, add-ons or integrations, and unavailable requirements. Ask who would maintain each workaround. A feature tick alone does not explain how the team would operate the process.
Keep the review centred on the gaps the process review found. Broader product selection and detailed case exercises answer separate questions.
Include the work of switching
List what agents must be able to find and act on at the switch: active cases, recent customer replies, relevant internal context, attachments, identity, owner and next action. Ask how each item would move or remain accessible. Export and import methods need separate checks.
Zendesk account data can be exported to JSON, CSV or XML, but data exports are not enabled by default. When tickets are imported into Zendesk through its documented API route, first-reply and first-resolution metrics are not imported. These are limits of specified methods, not universal migration limits.
Assign the work of mapping fields, connecting channels, checking access, training staff, reconciling cases changed during the switch and keeping a monitored reply route. Record any historical report that will need a labelled break or archive.
Record a revisitable decision
The decision record should name the unresolved gap, options considered, proposed plan, material limits, transition work, accepted risks and owner. Set conditions for moving ahead: the receiving team can find and act on active cases, and customers have a working reply path. State what would pause the switch.
The resulting decision may be to improve the current setup, add a limited capability or replace the platform. Revisit it if the requirements, proposed plan or transition assumptions change.
