Skip to main content
Ready to deploy? Start Free Trial
Documentation

Migrating from Odoo.sh

Backup upload, restore, verification, DNS cutover — usually under an hour, with Odoo.sh staying live as your rollback safety net.

Back to docs index

The four steps

  1. Assessment — share an Odoo.sh backup (or grant temporary read access). CloudWady detects version, addons, filestore size, and any custom modules.
  2. Restore — CloudWady provisions the app on your chosen cloud (Hetzner / DigitalOcean / AWS / your existing server), restores the database + filestore, and runs the standard post-restore checklist.
  3. Verification — you log in to the restored instance and verify key workflows (login, sales/purchase, reporting, automations). Cron and scheduled actions are wired but pointed at staging until you cut over.
  4. DNS cutover — you flip DNS. CloudWady monitors for the first 24 hours. Odoo.sh subscription stays live for 1–2 days as rollback safety, then cancels on your timeline.

What carries over (automatic)

  • Database (full Postgres dump).
  • Filestore (attachments, signed documents, images).
  • OCA / community modules, including pinned versions.
  • Custom modules — copied verbatim, no rewrites required.
  • Scheduled actions, automations, server actions.
  • Users, groups, permissions, partner data — everything in the database.

What changes (we'll tell you upfront)

  • SMTP / outgoing mail — needs reconfiguration with credentials you control (CloudWady doesn't ship its own SMTP relay).
  • Branch-per-environment workflows — translate to CloudWady's environment model (production / staging / development). Most teams keep the same branching scheme; the trigger plumbing moves to the dashboard.
  • Shell access — you get terminal + DB shell + filestore SSH directly on the server you own; no Odoo.sh-style sandboxed shell.
  • Cron / staging schedules — kept as-is on production; staging schedules are paused by default to avoid duplicate side-effects during verification.

What we accept on the way in

Backup format

Standard Odoo.sh backup ZIPs — the same files you download from the Odoo.sh backups tab. CloudWady detects format, decompresses, and ingests both the database dump and the filestore.

Versions

Odoo 14 through 19. Migrations between major versions are not part of the move; if you want to upgrade Odoo at the same time, that's a separate engagement on top of the move.

Sizes

No hard cap. The largest customer migrations have been multi-hundred-gigabyte filestores. For very large filestores we stream via rsync to keep the cut-over window small.

Why teams move

Cost

Odoo.sh dedicated grows linearly with project count; CloudWady's per-tenancy pricing keeps a multi-project bill predictable. See Billing & pricing and the comparison page for the math.

Data residency

You pick the region — EU servers in Hetzner Helsinki / Falkenstein for GDPR, or US/APAC where it makes sense. Odoo.sh's data centre choice is fixed.

Operational access

SSH + DB shell + filestore inspection on your own servers. No "managed black box" between you and the OS.

What we need from you

  • An Odoo.sh backup (or temporary read access to your project).
  • A target environment — either a CloudWady-managed server we provision, or your existing server we install on.
  • Domain control for the eventual DNS cutover (TTL ideally already at 300s).
  • A maintenance window for the cut-over — 30 minutes typical, usually after-hours or weekend.
Sales-side detail and pricing: see the migration marketing page for current offer terms (first tenancy free, partner discounts, etc.).
Back to all topics