# Migration and recovery runbook

Publication: OpenForex Society / OpenForex Foundation. Updated 2026-09-24.

## Scope
This runbook moves the current PHP documentation portal from one host to another. It does not change the monetary architecture or automatically migrate an optional wiki engine. Host-specific package versions, service names, and certificate configuration must be validated on the destination.

## Before migration
Inventory the public document root, sibling content directories, configuration, and any independently installed authoring engine. Record the current URLs and repository configuration. Identify the person responsible for cutover and define a maintenance window and rollback trigger.

Make a complete backup and verify that it can be opened and restored. Record checksums or another integrity comparison for transferred artifacts. A backup that has never been restored is incomplete recovery evidence.

## Stage the destination
Deploy the same application and content directory structure. Configure a PHP-capable web server with public_html as the public root. Keep source-only configuration and backups outside that root. Configure the intended domain and TLS using the destination host's supported process.

Use a staging hostname or local host mapping to verify the site before changing public routing. Do not assume the old host's filesystem paths, PHP process name, or permissions apply to the new host.

## Acceptance checks
- Homepage, article routes, and assets respond correctly.
- The document count and content match the source publication.
- Search, navigation, icons, tables, and downloads work.
- Unknown page identifiers return 404.
- Configuration and backup files are not publicly reachable.
- The repository destination and public support claims are correct.

If an authoring engine exists, back up its database or data directory and verify its authentication and permissions separately. A PHP portal backup is not automatically a Wiki.js database backup.

## Cutover and rollback
Freeze edits briefly or record a final content delta. Change routing only after acceptance checks pass, then repeat checks against the public hostname. Keep the previous deployment intact through the agreed observation period.

Rollback if critical reading routes fail, content is missing, or private files become exposed. Restore previous routing and reconcile any edits made after the snapshot before reopening authoring. Retain logs and the failed release for diagnosis.

See [shared hosting](?page=docs/shared-hosting-architecture) and [architecture](?page=docs/architecture).