Best Practices Summary

The following best practices come from the complete migration workflow and apply to any EPP Server upgrade or migration:

Planning

#	Best Practice
01	Migrate immediately — support for all 5.x versions ended 14 February 2026. Every day on a 5.x server is a day without security coverage. See Netwrix Endpoint Protector Server Supportability.
02	Test the complete migration procedure in a lab environment before executing in production.
03	Plan a maintenance window that is at least 2× your estimated migration duration.
04	Communicate the maintenance window to all affected stakeholders and end users in advance.
05	Verify the updated license (php_els field) before starting any migration activity.
06	Keep the old server VM alive until the new environment is fully validated. Never decommission prematurely.

Backup and Recovery

#	Best Practice
07	Always create a VM snapshot AND a System Configuration Backup — they serve different recovery purposes.
08	Store the System Backup Key in a password manager or secure vault. You can't recover it if you lose it.
09	Label all backups with version, date, and purpose (e.g., pre-patch-5942, migration-to-2510).
10	For compliance-regulated environments, export audit logs separately before migration — they aren't in the config backup.
11	Test backup restoration in a non-production environment at least once before relying on it for production recovery.
12	Create audit log backups to export logs off the server — don't use the server as a storage location. Backup files left on the server can be lost if the image fails or is replaced. Always download and store audit log backup files in a secure, external location.

Database and Infrastructure

#	Best Practice
13	Maintain at least 30% free disk space at all times — enforce this via monitoring before and after migration.
14	For databases over 50 GB, always engage Netwrix Support for supervised migrations.
15	Don't perform other server changes or upgrades for 24 hours after the 5.9.4.2 patch — background DB jobs are running.
16	Allocate additional CPU and RAM temporarily during migration — doubling resources can cut migration time by 2–3×. See Server Requirements for baseline recommendations.
17	Use SSD-backed storage for the EPP VM — spinning disk significantly increases upgrade and query times for large DBs. See Server Requirements for storage minimums.

Network and Security

#	Best Practice
18	Always reuse the same IP/FQDN for the new 2510 server. Changing it creates cascading certificate and Enforced Encryption (EE) trust failures.
19	Fill both DNS fields in network settings on 2510 — a known bug prevents saving with only one DNS entry.
20	Disable client communications on the new server before restoring a backup to prevent partial-state registrations.
21	After migration, monitor SIEM connectivity — it may require reconfiguration and Netwrix Support may need to provide a restoration script.

Client Management

#	Best Practice
22	If you are using EPP Server Client Upgrade feature, never upgrade Clients directly from 5.9.4.1 (or older) to 2511 or later clients — upgrade to 5.9.4.3 first as the signature bridge.
23	Use enterprise deployment tools (Intune, SCCM, Jamf) for client upgrades rather than relying solely on EPP's built-in (rate-limited to 50/hour).
24	Always run a pilot deployment of 10–20 endpoints before mass client rollout.
25	For Enforced Encryption (EE) environments, upload both Windows and macOS EE clients to the server before enabling client communications — the server requires both packages to be present regardless of which OS your endpoints use.
26	Plan client updates for off-peak hours to minimize end-user disruption.
27	If a Client Upgrade task is stuck, clean up all existing Client Upgrade tasks on the EPP Server and create a new task — stale tasks can block the upgrade queue.
28	If a Client Upgrade task doesn't start or remains stuck on a Windows endpoint, reboot the endpoint before retrying — the EPP Client installer uses msiexec, which can be blocked by a pending restart or a previous failed installation.

Backup Version Discipline

#	Best Practice
29	Create the migration backup on exactly version 5.9.4.2 — not 5.9.4.1, not 5.9.4.0. 2510 rejects any other version and may cause OS regression.
30	Label every backup file with the server version and date in the filename (e.g., epp-5942-backup-2026-04-21.bak). Mislabelled backups are a leading cause of wrong-version import errors.
31	You can restore a 2509 configuration backup onto a 2510 server — the OS remains 2510 and the result is functionally equivalent to a native 2510 deployment. The only consideration is disk sizing: verify that disk capacity is sufficient, as the 2509 base image uses a smaller default disk allocation than 2510.
32	After applying the 5.9.4.2 cumulative patch, wait 24 hours for background DB tasks to complete before creating the migration backup.

3rd-Party Integrations

#	Best Practice
33	Treat all 3rd-party integrations (SMTP, AD/LDAP, SSO, SIEM, S3) as not migrated until manually verified post-migration.
34	Document all integration credentials and settings before migration — have them ready for re-entry post-restore.
35	After AD Sync completes, verify the imported object count matches expectations — silent partial imports can occur even when sync reports success.
36	For SIEM integrations, contact Netwrix Support proactively after migration — restoration may require a specialized script.

Post-Migration Stability

#	Best Practice
37	Don't apply server patches immediately after backup restore — the import process can disrupt the patch pipeline. Allow 24 hours before patching.
38	Monitor Audit Log Backup jobs after migration — they can enter an infinite running state. Verify job completion before scheduling recurring backups.
39	For air-gapped / offline environments, obtain the Offline Activation Patch for 2510 before the maintenance window begins — request it from Netwrix Support in advance.