Migration guide: self-hosted to SaaS

This guide walks you through migrating from a self-hosted Arbitex Outpost deployment to Arbitex Cloud SaaS. It covers decision criteria, a pre-migration checklist, step-by-step migration procedures, configuration mapping, and rollback planning.

---

1. When to migrate

Migration to Arbitex Cloud SaaS is appropriate when your organization wants to reduce operational overhead and benefit from managed infrastructure. Common drivers:

Driver	Description
Managed infrastructure	Eliminate Outpost patching, scaling, and monitoring burden
Automatic updates	DLP models, regex patterns, and platform features update without manual intervention
Scaling needs	Cloud auto-scales with usage — no capacity planning required
Compliance features	Generated compliance reports and the documented shared responsibility model are available only on the managed deployment. Arbitex holds no certification or attestation under any framework — these are evidence for your own assessment, not a substitute for it.
Multi-region	Cloud Enterprise plan offers EU region data residency

When NOT to migrate

Migration is not appropriate in these scenarios:

• Air-gap requirement — Your environment has no internet egress. Cloud SaaS requires internet connectivity.
• Data residency mandates Cloud cannot meet — If regulations require data to remain in a specific jurisdiction not yet available as a Cloud region (currently US and EU-Enterprise only).
• On-premises contractual obligation — Contracts that explicitly require on-premises data processing.
• Custom model deployments — If you run custom DeBERTa fine-tunes that are not available on Cloud.

Note

If you are unsure whether Cloud meets your compliance requirements, contact your Arbitex account team for a data residency and compliance assessment before starting migration.

---

2. Pre-migration checklist

Complete every item before beginning migration steps.

2.1 Export current DLP rules

Export your Outpost DLP configuration using the admin API:

curl -s -H "Authorization: Bearer $ADMIN_TOKEN" \
  http://outpost-host:8301/admin/config/export \
  -o rules_backup.json

Verify the export contains your rules:

cat rules_backup.json | python3 -m json.tool | head -20

2.2 Document custom patterns

If you have added custom regex patterns beyond the standard 76-pattern set, document them separately. Custom patterns need manual re-creation in Cloud if they are not included in the config export.

2.3 Export audit logs

Cloud SaaS will not have your historical Outpost audit logs. Archive them locally before migration:

# Export audit logs from Outpost SQLite buffer
curl -s -H "Authorization: Bearer $ADMIN_TOKEN" \
  http://outpost-host:8301/admin/audit/export \
  -o audit_archive.jsonl

Store the archive according to your retention policy. If you use a SIEM integration, verify that historical logs are already ingested before decommissioning Outpost.

2.4 Inventory API keys

Document all API keys and JWT secrets used by client applications to authenticate with Outpost. After migration, these will be replaced with Cloud API keys.

2.5 Document LLM provider configurations

List all integrated LLM providers and their endpoint configurations. You will need to re-configure these in the Cloud portal:

• Provider name and model IDs
• Endpoint URLs
• Authentication credentials (API keys, OAuth tokens)
• Any custom headers or parameters

2.6 Review data residency obligations

Determine whether your data residency requirements are compatible with Cloud SaaS:

Cloud plan	Data region	Availability
Standard	US (East)	Available now
Enterprise	EU (Frankfurt)	Available now
Enterprise	Additional regions	Contact sales

If your current Outpost deployment exists specifically for data residency in a region Cloud does not support, migration may not be appropriate.

---

3. Migration steps

1. Create Arbitex Cloud account

   Contact your Arbitex account team to provision your organization. Once provisioning completes you receive an organization ID (org_id) and an invitation to the Arbitex admin console. If your organization requires Enterprise features (EU region, SSO, SCIM), raise them with your account team before proceeding.

2. Export Outpost DLP rules

   If you have not already done so in the pre-migration checklist:

   curl -s -H "Authorization: Bearer $ADMIN_TOKEN" \
     http://outpost-host:8301/admin/config/export \
     -o rules_backup.json

3. Import rules into Cloud

   In the Cloud portal, navigate to Settings → Config Import and upload rules_backup.json. The importer maps Outpost rule format to Cloud’s policy engine.

4. Verify imported rules

   After import, review the rules in Settings → DLP Policies:

   • Confirm the rule count matches your Outpost configuration
   • Spot-check 3–5 rules: verify entity types, actions, and priority order
   • Check that custom patterns imported correctly

5. Update application gateway URL

   In every client application that sends requests through Outpost, update the gateway URL:

   GATEWAY_URL=http://outpost-host:8300
   GATEWAY_URL=https://api.arbitex.ai/v1

6. Update authentication

   Replace Outpost JWT authentication with a Cloud API key:

   • In the Cloud portal, go to API Keys → Create
   • Name the key (e.g., production-gateway)
   • Copy the key immediately — it is displayed only once
   • Update client configuration:

   Authorization: Bearer <outpost-jwt-token>
   Authorization: Bearer <cloud-api-key>

7. Send a test request

   Send a single scan request through the Cloud endpoint and verify:

   • The request completes successfully
   • The scan result appears in the Cloud portal Audit Logs
   • DLP detection results match expected behavior

   curl -X POST https://api.arbitex.ai/v1/scan \
     -H "Authorization: Bearer $CLOUD_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"text": "My SSN is 123-45-6789", "model": "test"}'

8. Parallel run (recommended)

   Run both Outpost and Cloud SaaS simultaneously for 48–72 hours:

   • Configure a subset of traffic (or a staging environment) to use the Cloud endpoint
   • Compare audit outputs between Outpost and Cloud
   • Verify DLP detection parity
   • Monitor Cloud billing to confirm expected usage

   Tip

   During parallel run, do not decommission Outpost. Keep it fully operational as your fallback.

9. Cutover

   After successful parallel run, update all remaining client configurations to the Cloud endpoint. Coordinate the cutover during a maintenance window if your organization requires one.

10. Decommission Outpost

    After confirming all traffic flows through Cloud SaaS:

    • Stop the Outpost process
    • Archive Outpost configuration files and logs
    • Retain the archive for at least 14 days (rollback window)
    • Remove Outpost infrastructure (containers, VMs, PVCs)

---

4. Configuration migration reference

This table maps Outpost environment variables to their Cloud portal equivalents.

Outpost env var	Cloud equivalent	Notes
OUTPOST_JWT_SECRET	Cloud API key	Portal → API Keys → Create. Key-based auth replaces JWT.
DLP rule configuration (JSON)	Portal → Settings → Config Import	Upload rules_backup.json from admin export.
LOG_ROTATION_MAX_SIZE	Managed by Cloud	Cloud handles log rotation automatically.
LOG_ROTATION_MAX_FILES	Managed by Cloud	Not applicable — Cloud retains logs per plan retention policy.
DISK_MONITOR_THRESHOLD	Managed by Cloud	Not applicable — Cloud manages storage.
DISK_MONITOR_CHECK_INTERVAL	Managed by Cloud	Not applicable.
DEBERTA_MODEL_PATH	Managed by Cloud	Cloud manages model deployment and updates.
TLS_CERT_PATH	Managed by Cloud	Cloud manages TLS termination at the edge.
TLS_KEY_PATH	Managed by Cloud	Cloud manages TLS termination at the edge.
TLS_CA_BUNDLE	Managed by Cloud	Not applicable.
RATE_LIMIT_SCAN_PER_MINUTE	Portal → Settings → Rate Limits	Configurable per-plan.
RATE_LIMIT_ADMIN_PER_MINUTE	Managed by Cloud	Admin API rate limits managed by Cloud.
SIEM_DIRECT_TYPE	Portal → Integrations → SIEM	Cloud supports Splunk HEC, syslog, and webhook.
OUTPOST_AIRGAP	Not applicable	Cloud requires internet connectivity.
OUTPOST_PEERS	Not applicable	Cloud is single-tenant SaaS — no peer mesh.

Caution

Environment variables not listed above may have Cloud equivalents in the portal settings. Check the Cloud portal documentation or contact support for unlisted variables.

---

5. Data residency notes

Arbitex Cloud SaaS processes and stores data in the following regions:

Plan	Default region	Additional regions
Standard	US East (Virginia)	—
Enterprise	US East (Virginia)	EU (Frankfurt) on request

Considerations

• US Standard plan: All data (prompts, scan results, audit logs) is processed and stored in US East.
• EU Enterprise: Data processing and storage in EU. Requires Enterprise plan activation — contact your account team.
• If data residency is the reason for Outpost: Evaluate whether Cloud’s available regions meet your requirements before migrating. If they do not, Outpost remains the appropriate deployment model.
• Transit encryption: All data in transit to Cloud uses TLS 1.2+ encryption. Data at rest is encrypted with AES-256.

---

6. Rollback plan

Keep Outpost operational for at least 14 days after cutover. If issues arise with Cloud SaaS, rollback is straightforward.

Rollback procedure

1. Revert gateway URL in all client applications:

   GATEWAY_URL=https://api.arbitex.ai/v1
   GATEWAY_URL=http://outpost-host:8300

2. Revert authentication to Outpost JWT tokens:

   Authorization: Bearer <cloud-api-key>
   Authorization: Bearer <outpost-jwt-token>

3. Verify traffic flows through Outpost by checking audit logs.

4. Investigate the Cloud issue — contact Arbitex support with details.

Note

During the 14-day rollback window, keep Outpost configuration and infrastructure intact. Do not decommission until you are confident Cloud SaaS is operating correctly.

Rollback limitations

• Audit logs generated during the Cloud period remain in Cloud — they are not automatically synced back to Outpost.
• Any rule changes made in the Cloud portal after migration will need to be manually re-applied to Outpost if you roll back.

---

7. Post-migration verification checklist

After cutover, verify each item before considering migration complete.

Check	How to verify	Expected result
Audit logs visible	Portal → Audit Logs	Recent scan requests appear with correct timestamps
DLP rules active	Send test content with known PII	Correct detection and action (block/redact/log)
API usage tracking	Portal → Billing → Usage	API call counts increment with each request
Webhooks configured	Portal → Settings → Webhooks	If you used Outpost webhooks, re-configure in Cloud and verify delivery
SIEM integration	Check SIEM for incoming events	Audit events flow from Cloud to your SIEM connector
LLM providers connected	Portal → Providers	All providers show connected status
User access	Team members can log in to portal	SSO/SAML works if configured
Alerting	Trigger a test alert condition	Alert notifications delivered to configured channels

Tip

Keep this checklist as a runbook. Re-verify after any Cloud configuration changes during the first 30 days post-migration.

---

Related pages

• Outpost deployment guide
• Air-gap deployment guide
• Cloud portal administration
• API key management
• DLP pipeline configuration