5 Essential Handover Preparations Before Outsourcing Server Maintenance

A significant portion of outsourcing issues stem not from technical problems, but from missing handover information—the new team doesn’t know which servers exist, where passwords are stored, or what was changed last time. This forces them to ask you for every step, actually slowing down resolution.

The following 5 items must be prepared before handover. Their common goal is: enabling the other party to handle incidents independently without asking you.

Item 1: Account and Permission Inventory

Two principles:

• Do not provide root/master accounts directly. Master accounts have excessive permissions and are often tied to your phone number and payment info. Instead, create sub-accounts with least-privilege authorization.
• The inventory should specify “what can be done”, not just list accounts. Otherwise, the other party won’t know if they have permission for a specific machine.

Item 2: Keys and Credentials

• SSH private keys (do not send via chat apps)
• Database root and application account passwords
• All API Keys and Secrets
• Certificate private keys (if any)

Delivery method matters: Use encrypted channels for transmission, and rotate credentials after handover. Chat logs and email bodies retain keys indefinitely, creating a common leakage vector.

# Recommended action after handover: Rotate critical credentials
# SSH: Generate new key pair, replace authorized_keys
ssh-keygen -t ed25519 -C "newkey"

# Database: Change password
mysql -e "ALTER USER 'appuser'@'localhost' IDENTIFIED BY 'NewPassword';"

Item 3: Topology and Dependency Documentation

This is the most commonly omitted item and the easiest to misjudge. At minimum, clearly document:

• Number of machines and services running on each
• Dependencies: Web → App → Database; which machine hosts the database
• External dependencies: Which third-party APIs are called and impact if they fail
• Single points of failure: Which machine failure causes total outage

Example (Simplified Topology):
  web-01  1.2.3.4   Nginx + PHP-FPM   Public 80/443
  db-01   1.2.3.5   MySQL 8.0         Internal only, connected by web-01
  oss     Object Storage   Stores user uploads
  External Dependencies: Payment API (timeout causes order failure)

Even a few lines of text allow the other party to immediately identify which server to check first during an incident, rather than troubleshooting one by one.

Item 4: Change Logs and Known Issues

• Recent changes made (especially non-standard operations)
• Known but unresolved issues (e.g., occasional scheduled task failures)
• Reasons for special configurations (why it’s configured this way, to prevent being “optimized” away)

The third point is practical: Some seemingly unreasonable configurations have valid reasons. If not documented, the接手 person may “fix” it, triggering a previously resolved issue.

Item 5: Emergency Contacts and Escalation Path

• Who gets notified under what circumstances
• Who to contact if unreachable (escalation path)
• Which operations require prior approval (e.g., restarting databases, changing DNS)

The last point must be clear. Some operations have wide impact; automatic execution is not allowed by default and must be explicitly listed.

Handover Document Template

1. Accounts and Permissions
   - SSH: Address/Port/Method, permission scope
   - Cloud Console: Sub-accounts, manageable instances
   - Domain/DNS: Management portal

2. Keys and Credentials (Encrypted delivery, rotated after handover)
   - SSH Private Key / DB Password / API Key

3. Topology and Dependencies
   - Machine List: IP + Role
   - Dependencies: Who connects to whom
   - External Dependencies: What breaks affects what

4. Changes and Known Issues
   - Recent changes
   - Known unresolved issues
   - Reasons for special configs (to prevent removal)

5. Emergency Protocols
   - Who to notify, trigger levels
   - Escalation path if unreachable
   - List of operations requiring prior approval

Post-Handover Verification

Providing documents does not mean they are usable. Conduct a practical verification:

• Can the other party independently log in to all listed systems?
• Can they locate critical configurations?
• When an alert occurs, can they determine which server to check first without reading the docs?

The most direct verification method: Simulate a minor incident and observe if their response path requires asking you. Areas where they ask indicate gaps in the documentation.

Decision Tree

Preparing Handover
├─ Accounts: Provide sub-accounts, not master; specify permission scope
├─ Credentials: Deliver via encrypted channel, rotate after handover
├─ Topology: Machine list + dependencies + single points of failure
├─ Changes: Recent changes + known issues + reasons for special configs
├─ Emergency: Who to notify + escalation path + operations requiring approval
└─ Verification: Simulate incident, check if questions are needed → Questions indicate gaps

After Handover
└─ Update docs regularly (modify upon change, otherwise docs become obsolete quickly)

Scenario Walkthrough: Two Weeks Post-Handover, Midnight Incident Login Failure

Phenomenon: Servers handed over to the new team two weeks ago; everything normal during the day.
One night, an incident occurs, and the new team cannot log in to handle it, leading to lengthy communication delays.

1. Determine the category of login failure → Account exists, password is correct,
   but login is rejected by policy. This indicates it’s not a credential issue, but an access restriction.
2. Check the source of access restrictions → Remote service configured with source IP whitelist,
   allowing only the original team’s office network.
3. Add whitelist and verify login → Add the new team’s exit IP and verify immediately,
   verification must be done then, not waited until next incident.
4. Check other systems with similar restrictions → Admin backends, databases, cloud consoles may have their own whitelists;
   fixing one isn’t enough.
5. Verify emergency contacts are actually reachable → Try contacting during off-hours,
   confirm someone is available and can take over.
6. Add this omission to the handover checklist → Access restriction items (whitelists, 2FA devices, keys) should be a separate category.

# Check both types of source restrictions
# SSH whitelist and security policies
grep -iE 'allowusers|allowhosts' /etc/ssh/sshd_config
cat /etc/hosts.allow /etc/hosts.deny 2>/dev/null
firewall-cmd --list-all 2>/dev/null | head -20

# Cloud platform access control (Security Groups) can only be checked in the console, not on the server

# Handover acceptance method: Actually log in using the new team's account
ssh -i NewKey User@Server 'echo Login OK; uptime'

Root Cause: The handover checklist covered accounts and credentials but missed “source access restrictions”.
Testing passed during the day on the original network, masking the fact that access from other networks at night would be denied.

Two key takeaways:

• Handover acceptance must involve actual login using the new team’s network environment and accounts.
  Passing tests on the original office network does not guarantee access from anywhere else.
• Access restrictions must be verified as a separate category.
  Host whitelists, admin backend limits, and cloud security groups are independent layers; fixing one doesn’t open all.

Acceptance Criteria for Completed Handover

The acceptance criteria column is the most important yet most often omitted part of handover.
“Providing accounts” and “Maintenance team can log in independently” are two different things;
the former is an action, the latter is a result. Acceptance based on results is the only way to consider handover complete.

Three Verifications After Handover

1. Log in once using the maintenance team’s own accounts: Avoid shared accounts; verify permissions are correctly granted.
2. Walk through the emergency contact path: Test during off-hours to confirm reachability and login capability.
3. Ask the team to recount the handling procedure for a known issue: If they can recite it, it proves the documentation was understood.

# Pre-handover: Confirm existing login accounts and sudo privileges (avoid discovering only shared accounts exist after handover)
awk -F: '$3>=1000 && $7 !~ /nologin|false/ {print $1, $3, $7}' /etc/passwd
grep -E '^s*[a-zA-Z0-9_-]+s+ALL=' /etc/sudoers /etc/sudoers.d/* 2>/dev/null

# Confirm key-based login works (old keys must be revoked after handover)
grep -c 'ssh-' ~/.ssh/authorized_keys
last -10

The third verification (asking them to recount) seems redundant but is the only way to discover “docs written but not understood”.
Handover failures usually don’t happen during handover, but at midnight during the first incident—
at that time, no one reads the docs; success depends on whether consensus was truly formed during handover.

8 Common Pitfalls

1. Giving master accounts directly: Excessive permissions and tied to personal info.
2. Sending keys via chat tools: Permanently retained, high leakage risk.
3. Not rotating after delivery: More hands increase risk.
4. Omitting topology: Don’t know which server to check first during incidents.
5. Omitting reasons for special configs: Successors may “fix” them incorrectly.
6. No escalation path: Stuck if primary contact is unreachable.
7. Not updating docs: Become obsolete after a few changes.
8. Assuming completion without verification: Must simulate an incident to find gaps.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar O&M services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and peers, provided for reference only, not fictional tickets from this site):

10***44 2026-09-09 5.0 Comprehensive features | Easy to use | Clean interface Very useful. Supports latest WordPress 7.1 system

1****1 Rating: 5.0 Points 2020-06-18 11:51 Many thanks! He****She Rating: 5.0 Points 2020-04-21 15:04 Boss is great! Configuration was fast! No pauses! Good, good! 1

b****4 Rating: 5.0 Points 2025-06-23 16:57 b****4 Rating: 5.0 Points 2025-06-23 16:56 Jian****Wei Rating: 5.0 Points 2021-01-20 15:03 Tech skills are awesome, speed is fast! It turned out to be a Trojan causing Baidu global hijacking!!!!1 f****u Rating: 5.0 Points 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 Points 2020-11-20 10:03 Consistently good service 1****1 Rating: 5.0 Points 2020-11-17 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 Points 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 Points 2020-08-24 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 Points 2020-07-24 09:49 Many thanks! 1