Platform Migration
Support platform reliability
Define the support paths that must work, spot partial failures, prepare for disruption and check recovery and vendor commitments.
A reliable support platform lets the team receive a request, find what it needs to act, send a reply and recover unfinished work after a disruption. Test those paths separately: a working login does not prove incoming messages, connected records or outgoing replies are working.
Define the service the team needs
Identify customer requests that cannot wait for the platform to recover. For each, name the receiving channel, case owner, information needed for the next decision and reply route.
Agree how long the work can wait and how much recent history the team could afford to lose. Compare those needs with vendor recovery terms.
| Support path | Failure to recognise | Operating question |
|---|---|---|
| Intake | A message does not enter the queue | Where will the team find and acknowledge it? |
| Agent access | Staff cannot open a case or its history | Which urgent cases can still be worked? |
| Connected data | An order or account panel is stale | How will an agent check the source record? |
| Outbound reply | A send is recorded but the customer receives nothing | Who checks delivery and follows up? |
| Recovery | Work is missing or duplicated after service returns | Who reconciles the interruption period? |
Watch the whole path
Use the vendor’s status information as one signal. Zendesk displays incidents for a customer’s subdomain and service history by product and feature.
That view does not establish the health of the customer’s separate mail or data connections. Atlassian says its Statuspage communicates incidents but does not directly monitor websites or servers. Compare notices with what agents and customers can actually do.
Choose operational checks for each critical path: a test request reaching the queue, an agent opening a representative case, a controlled lookup and a reply received at a test destination. Decide which checks can run safely and who reviews a failure. Keep an incident open while a critical path remains broken, even if platform status appears healthy.
Prepare for disruption and recovery
Name who declares a support disruption, communicates with customers and tracks unfinished cases. Keep the communication route usable when the helpdesk is unavailable.
Use an authorised, limited register for urgent new contacts and commitments, with a temporary reference and owner. Mark information that may be stale.
For a detailed exercise to verify access to critical support records during a disruption, see the supporting article.
When service returns, reconcile temporary records, messages received elsewhere, customer replies and actions taken during the gap. Assign an owner to each unresolved case.
Set backup arrangements against the data, applications and configuration that must be restored to meet the team’s recovery objectives. Where data can be reproduced from another source, document that option; otherwise, identify it for backup. AWS guidance also recommends securing and encrypting backups, performing them automatically, and periodically recovering data to verify backup integrity and processes.
Read status signals in context
Zendesk’s status page shows current active incidents and a 90-day service history organised by product and feature. It gives basic and detailed incident information. When an incident is identified, an “investigating” banner appears; more specific information replaces it as it becomes available.
Zendesk separates the view for a customer’s subdomain from its view of all data centres. Check which view you are using when comparing a vendor notice with a support problem, so a system-wide status is not mistaken for a subdomain-specific account of service health.
A Zendesk subdomain status page is visible to anyone who knows the subdomain. If a problem is not shown there, Zendesk directs customers to create a support ticket. Record this escalation route in the team’s operational procedure so an absent status notice does not leave the problem without an owner.
Zendesk incident lifecycle: from detection to resolution
- Incident identified
- “Investigating” banner appears on status page
- Detailed information available
- Specific cause and impact details updated
- Resolution confirmed
- Incident closed with summary of actions taken
Set useful monitoring signals
Monitoring can track latency, error rates and resource use, with alerts when these measures cross critical thresholds. Choose measures that reveal a failure affecting a support path, and make sure the team knows who receives and reviews an alert. End-to-end visibility across services and applications can help identify where a failure is occurring.
Map critical components and their dependencies before an interruption. Failure Mode and Effects Analysis (FMEA) is one technique for identifying components susceptible to failure and considering how their failure could affect dependent applications. Use the results to prioritise which parts of the support service need closer monitoring and recovery preparation.
Key reliability metrics for support platforms
- Backup frequency
- Automated daily with verification
- Data encryption
- At rest and in transit
Review and rehearse
Ask what the vendor counts as available, which functions and integrations are covered, how incidents are reported and which recovery terms apply to the proposed plan. Keep an uptime commitment, a support response target and the team’s own continuity procedure distinct.
Rehearse a scenario in which the workspace is unavailable, a connected lookup is stale and a customer replies through a fallback route. Check who notices each problem, what the customer hears, where the work is recorded and how it is reconciled. Assign changes to monitoring, access, communication or the vendor review.
In this guide
- Planning customer communication during a helpdesk outagePrepare an outage message, an independent update route, an owner and a reliable update cadence while support is disrupted.
- Testing access to critical support records during disruptionCheck whether agents can retrieve usable, current and appropriately restricted case records when their helpdesk is disrupted.
- Monitoring integration delays that affect agentsMeasure the age of information agents see, combine queue and delivery signals, and respond safely to stale connected data.
- Reviewing incident response commitments with a vendorRead availability, support and recovery terms against the support functions your team needs, including exclusions and claim routes.
