Migrate from a Jenkins-managed setup

Use this journey when the host already runs DataMind OS from a legacy Jenkins-managed setup and you are moving it to the Docker stack that the DataMind Installer manages. The migration retires the old platform services on the host, imports your configuration values, and opens the configuration editor so you can finish the setup.

Before you start

• An administrator account in the DataMind Installer. Every migration action is admin-only, and roles are set on Users. If the Installer is not on the host yet, start with Install on a fresh host.
• The legacy VM user. That is the OS user that owns the legacy setup on the host, for example ubuntu. The Installer substitutes it for the <USER> placeholder in the host paths it generates.
• The Jenkins configuration on the host. The import reads it, so leave it in place until the migration has finished. Without the file you fill the values by hand.
• No other job running. The Installer runs one operation at a time and refuses to start the migration while another job is active; the lock is described on Start, stop, restart and terminate DataMind OS.

Run the migration from the Installer

1. From the setup view, click Start. The chooser Set up DataMind OS asks Is this a fresh install, or are you migrating an existing Jenkins-managed setup?

2. Choose Migrate from Jenkins (Retire an existing Jenkins-managed setup and carry its configuration over.).

3. Fill the Migrate from Jenkins modal:

   • Platform URL: the public address where users will reach DataMind OS, placeholder localhost or your-server.com (the address rules are on TLS and certificates).
   • DataMind Platform API key: paste your key. While no key is stored, the modal also shows Azure client secret (Azure client secret (only without a platform API key)); use it only if DataMind issued you one instead of a key.
   • Legacy VM user: the OS user from the list above, placeholder Legacy VM user (e.g. ubuntu).
   • SSL certificate path (optional) and SSL key path (optional): the certificate and key files on the host, if you serve DataMind OS over HTTPS.

   The modal points out anything missing: Platform URL is required, Enter a valid address (e.g. localhost or example.com), DataMind Platform API key is required, or VM user is required for migration. Click Save & continue (Saving… while it works).

4. Confirm the retirement. The dialog Retire the old platform? says This stops and permanently disables the legacy bare-metal DataMind OS services on the host, then imports your Jenkins configuration. Data volumes are preserved, but the old services won't start again. This can't be easily undone. Click Retire & migrate to run it, or Cancel to go back.

5. Watch the run in the same dialog:

   • It leads with Retiring the legacy platform…, then Importing Jenkins configuration…, and streams the output into the panel (Starting… appears until the first output arrives).
   • When it finishes, the dialog reads Migration complete and adds a summary line such as N values imported from Jenkins (1 value imported from Jenkins for a single value).
   • If it fails, the dialog reads Migration failed with the reason, and offers Retry migration or Skip to configuration.
   • The run is a tracked job: it stays in the Job Logs panel on Service status, and if you open the Installer again while it runs, it picks the job up and reports Host migration finished or Host migration failed when it ends.

6. Review the imported values. The configuration editor opens by itself; Review configuration reopens it later. Check what the import filled, set what is missing, then continue like a fresh installation: Save changes, then Start Installation. The full steps are on Install on a fresh host, and the editor is described on Configuration. When the installation finishes, sign in to DataMind OS for the first time: First sign-in to DataMind OS.

What the migration does on the host

• The retirement acts only on the fixed list of legacy platform services. It stops each one, waits for the stop to finish, and force-kills only a service that overruns its stop window (60 seconds by default). Each service is then disabled and masked so it cannot start again.
• It never touches Docker itself, the operating system, or Jenkins.
• Your Jenkins installation is left running on purpose, so its stored values stay readable.
• The NFS share the legacy setup exported is retired: its export lines are removed from the host after a timestamped backup.
• Containers left over from the old setup are removed, while their data volumes are kept for the new deployment to adopt.
• The run writes a full log on the host, and the same output streams into the dialog.
• If the job is cancelled, its output ends with Cancelled by operator, and everything the run had already retired stays retired.

Run the migration by hand

On a host where the legacy platform is retired before the DataMind Installer is deployed, run the migration script first and on its own, as root:

sudo ./migrate-host.sh

It performs the same retirement from the host side. It acts only on the fixed service list, never touches Docker, the operating system, or Jenkins, and finishes by naming the next steps: deploy the DataMind Installer, set its environment values, then start DataMind OS.

• Preview it with sudo ./migrate-host.sh --dry-run first. The dry run prints every step and changes nothing.
• Without the dry run it asks Proceed? [y/N] before it does anything.
• It refuses to run when it is not root: ERROR: run as root (sudo). On a host without systemd it refuses with ERROR: not a systemd host.
• It checks Docker before it touches anything, because Docker runs the platform afterwards. When Docker is not running, it stops with Start Docker first, or pass --force.; start Docker and run it again.
• Like the Installer's migration, it stops, disables and masks the legacy platform services, tears down the NFS share, and removes leftover containers while keeping their volumes.

After that, continue with Install on a fresh host: deploy the DataMind Installer, review the configuration, and start the deployment.

Questions, answered

What does the migration import?

The values stored in your Jenkins configuration. Each key is matched to the configuration editor: a value is written only where the row is still open, which means not a row you have already filled, not a fixed value, and not a computed memory row. Two legacy keys are renamed on the way in: MINIO_ROOT_USER becomes RUSTFS_ROOT_USER, and MINIO_ROOT_PASSWORD becomes RUSTFS_ROOT_PASSWORD. Nothing is written until the import runs.

What happens to my data?

It is kept. The retirement stops, disables and masks the old services, but it does not delete their data: leftover containers from the old setup are removed while their volumes stay on the host, ready for the new deployment to adopt. The confirmation puts it as Data volumes are preserved.

Can I undo the migration?

Not in one step. The services are stopped, disabled and masked, and the dialog warns that the step cannot be easily undone. The host keeps the moved service files and a backup of the export lines the run changed, and the run's own output says where they were moved, so an operator can restore them by hand. The Installer itself offers no undo.

Which user do I enter as the legacy VM user?

The OS user that owns the legacy setup on the host, for example ubuntu. The Installer writes it into the generated host paths that contain the <USER> placeholder.

The migration refused to start. What is missing?

It needs the platform address and the legacy VM user. Fill Platform URL and Legacy VM user in the migration modal and run it again: without them, the run is refused with PLATFORM_URL must be set before running host migration or VM user must be set before running host migration.

What if the Installer cannot find my Jenkins configuration?

Then there is nothing to import. The run reports that the file was not found and that you fill the values manually; when the file is missing altogether, only the default host paths are applied and the rest is left to you. Complete the values in the configuration editor after the migration.

Why do two imported values arrive with RUSTFS names?

The legacy setup stored them as MINIO_ROOT_USER and MINIO_ROOT_PASSWORD. The new deployment uses RUSTFS_ROOT_USER and RUSTFS_ROOT_PASSWORD instead, so the import renames them and keeps their values.

What does N values imported from Jenkins count?

The number of configuration rows the import filled. Values with no matching open row are skipped and not counted, and rows you had already filled keep your values.

The migration failed. What should I do?

Read the reason under Migration failed and the full output in the dialog's log panel. Fix the cause it names, then click Retry migration; or click Skip to configuration to carry on and fill the values by hand. When the message reads Host migration exited with code <code>, the number is the retirement script's exit code; read the log above it to see where the run stopped. Troubleshooting covers the common failure causes.

Does the migration touch Jenkins?

No. The retirement acts only on the fixed list of legacy platform services and leaves Jenkins alone: it keeps running so its stored values stay readable. The migration only reads your Jenkins configuration when it imports the values.