Private
Public Access
Migration Workflow hinzugefügt
@@ -0,0 +1,163 @@
|
||||
# Migration Workflow
|
||||
|
||||
This page describes the target migration workflow from an existing Romexis server into the Docker-based Romexis stack.
|
||||
|
||||
---
|
||||
|
||||
## Source System
|
||||
|
||||
The source system is usually a Windows-based Romexis server.
|
||||
|
||||
Required data:
|
||||
|
||||
```text
|
||||
SQL Server database backup (.bak)
|
||||
Romexis image directory
|
||||
Romexis ergo data directory
|
||||
optional Romexis cache directory
|
||||
```
|
||||
|
||||
The cache directory is optional because it can usually be regenerated.
|
||||
|
||||
---
|
||||
|
||||
## Target System
|
||||
|
||||
The target system runs:
|
||||
|
||||
```text
|
||||
Romexis Server container
|
||||
Database backend container
|
||||
Migration Service container
|
||||
Persistent data volumes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
```text
|
||||
Existing Romexis Server
|
||||
|
|
||||
| database backup
|
||||
| image data
|
||||
| ergo data
|
||||
v
|
||||
Romexis Migration Service
|
||||
|
|
||||
| validation
|
||||
| database restore
|
||||
| data restore
|
||||
v
|
||||
Docker-based Romexis Server
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Manual Workflow
|
||||
|
||||
1. Open the migration Web UI.
|
||||
2. Create a new migration job.
|
||||
3. Upload the database backup in the browser.
|
||||
4. Let the service create `manifest.json`.
|
||||
5. Trigger database restore.
|
||||
6. Upload images and ergo data via SFTP.
|
||||
7. Mark upload complete.
|
||||
8. Validate uploaded data.
|
||||
9. Run restore.
|
||||
10. Complete migration.
|
||||
11. SFTP credentials are removed or disabled.
|
||||
|
||||
---
|
||||
|
||||
## Client-Assisted Workflow
|
||||
|
||||
The migration client is intended to automate most source-side steps:
|
||||
|
||||
1. detect Romexis installation
|
||||
2. detect database configuration
|
||||
3. detect data directories
|
||||
4. create or use a migration job
|
||||
5. create database backup
|
||||
6. upload data through rclone/SFTP
|
||||
7. call API endpoints to advance the workflow
|
||||
8. show logs and restore status
|
||||
|
||||
---
|
||||
|
||||
## Expected Upload Layout
|
||||
|
||||
```text
|
||||
/upload/
|
||||
├── meta/
|
||||
│ └── manifest.json
|
||||
├── database/
|
||||
│ └── Romexis_db.bak
|
||||
├── romexis_images/
|
||||
├── romexis_ergodata/
|
||||
└── romexis_cache/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Manifest
|
||||
|
||||
The manifest describes the uploaded migration data.
|
||||
|
||||
Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"migration_id": "example",
|
||||
"name": "Example Migration",
|
||||
"source_host": "old-romexis-server",
|
||||
"database": {
|
||||
"backup": "database/Romexis_db.bak"
|
||||
},
|
||||
"romexis_images": true,
|
||||
"romexis_ergodata": true,
|
||||
"romexis_cache": false
|
||||
}
|
||||
```
|
||||
|
||||
The manual browser workflow can generate this automatically after database upload.
|
||||
|
||||
---
|
||||
|
||||
## Validation
|
||||
|
||||
Validation should check:
|
||||
|
||||
- manifest exists
|
||||
- database backup exists
|
||||
- image directory exists
|
||||
- ergo data directory exists
|
||||
- optional cache directory exists if requested
|
||||
- file counts
|
||||
- total bytes
|
||||
- future checksum data
|
||||
|
||||
---
|
||||
|
||||
## Restore
|
||||
|
||||
The restore step performs or coordinates:
|
||||
|
||||
1. database restore
|
||||
2. file placement into target volumes
|
||||
3. permission fixes
|
||||
4. Romexis restart
|
||||
5. final status reporting
|
||||
|
||||
---
|
||||
|
||||
## Completion
|
||||
|
||||
After successful restore, the job should be marked completed.
|
||||
|
||||
Completion should:
|
||||
|
||||
- remove or disable temporary SFTP user
|
||||
- hide workflow action buttons
|
||||
- keep logs available
|
||||
- preserve migration state file for audit/debugging
|
||||
Reference in New Issue
Block a user