Privacy & Security

Privacy & Security at a glance

Exactly what Odoo Migrator can see, what it never touches, and how long we keep it. The detailed Data Retention & Deletion Policy and Security Overview follow below.

What we access

• Your source, read-only — on GitHub via the App installation token, on GitLab via the OAuth connection or the personal access token you supply, and only on the repositories you grant. We read manifests, modules and submodules to plan the migration.
• One branch + one change request, write — we push the migrated code to an ll-migrate/<src>.0-to-<tgt>.0-<id> branch and open a pull request (a merge request on GitLab). We write no other branch, and nothing is merged; every change is yours to review.
• Your identity on that host — so we only ever show you your own organizations, groups and repositories, and scope every migration to your account.

What we never touch

• Your production database. This service migrates the code half of an Odoo.sh upgrade. The data upgrade stays with Odoo's own platform (use Odoo.sh Test Upgrade to rehearse it).
• Your running Odoo. We never deploy, never write to any branch but the migration branch above, and never touch live environments.
• Secrets in your repo. We read your code only to migrate it, and only for your own migrations. To do the work we mirror your modules into an isolated working repository; how long that copy lives is set out in the retention policy below.

How results are verified

The migration is produced by AI following defined processes and curated Odoo migration knowledge. Every run must then clear a structural quality gate: models, fields, views, actions and access rules are diffed against a baseline of stock Odoo on the target version, and the ported code must pass static, server and browser tests. Below the threshold the run is blocked (for you to review), not delivered.

Migrations are produced by AI following defined processes and curated Odoo migration knowledge — the best possible starting point, not a finished product. A developer must review, test, and fix the delivered code before it goes to production. We don't guarantee the migrated code works as-is.

Sub-processors

GitHub or GitLab (whichever hosts your source, and where we open the pull or merge request), Hetzner (EU hosting), the Lastloop platform (sign-in, workspace tenancy and credit balances, same EU cluster), Stripe (card payments for credit top-ups — we never see full card numbers), and the AI model provider we use to process your code during a run. No third-party analytics. The binding list is in the Data Processing Agreement.

Deleting your account

Signed-in partners can delete their account and all associated data themselves, under Account in the app.

Odoo Migrator — Data Retention & Deletion Policy

This policy describes the retention behaviour as actually implemented in the Service. Each window below corresponds to a control in the running system.

Owner: Last Loop GmbH, Darwingasse 20/29, 1020 Wien, Austria (FN 676580x)
Effective date: 27 August 2026

1. Principles

We retain personal data and code-derived data only as long as needed to operate the Service, meet legal/audit obligations, and support you — then delete it. You can trigger deletion of your own data at any time (self-serve erasure).

2. What we store and how long

In this table, final state means a migration has reached done, failed, cancelled or blocked. Retention windows are measured from the migration's last update, not from its creation — a blocked run that you retry restarts the clock.

Note on source code: to perform a migration we mirror the modules you select into an isolated working repository, and that copy is retained for up to RETENTION_DAYS (default 90 days) after the run reaches a final state — it is not deleted at the end of the run. You can remove it sooner by deleting your account, which purges working repositories immediately. We do not take any other durable copy of your repository: we never mirror branches you did not select, and the migrated output is delivered to your forge, under your control.

3. Self-serve erasure (right to be forgotten)

Under Account in the app you can permanently delete your account. This:

1. cancels any in-flight migrations, so nothing keeps running;
2. revokes the stored forge connection;
3. deletes the mirrored working repositories holding copies of your modules;
4. deletes, in a single transaction: your sealed forge tokens, all your migrations, their events, and any one-time credentials; then the account record;
5. logs you out.

Steps 1–3 are best-effort: if a working repository cannot be deleted at that moment it is recorded for manual removal, and the account deletion still completes. The database deletion in step 4 is atomic — it either fully succeeds or is rolled back.

Pull requests already delivered to your own repositories are not affected — they are yours.

4. Automated retention job

A background job (running on a single elected instance, every six hours) handles migrations that have been in a final state for longer than RETENTION_DAYS (default 90). For each it:

1. purges the migration evidence (gate-evidence timeline and phase logs);
2. deletes the mirrored working repository holding the copy of your modules;
3. deletes that repository's one-time push credential, so the credential never outlives the code it was issued for.

The lightweight audit row is kept so history and billing remain accurate; the bulky and sensitive material is removed.

5. Backups

Deletion requests are honoured in the live systems immediately. Backups of the service database are held by the platform on EU infrastructure and rotate out on a fixed schedule; a deletion is therefore fully propagated once the last backup predating it has rotated. Backups are used only for disaster recovery, are not queried in normal operation, and are subject to the same access controls and encryption in transit as production.

[TO CONFIRM WITH THE PLATFORM/INFRA TEAM BEFORE PUBLICATION: the exact backup retention window, so the sentence above can state a number of days. This is an infrastructure question, not a legal one.]

6. Legal holds

We may retain data beyond these windows where required by law, to resolve disputes, or to establish, exercise or defend legal claims. Where we do, the data is restricted to that purpose and deleted once it no longer applies.

7. Configuration reference (for auditors)

• Evidence and working-repository retention window: RETENTION_DAYS environment variable (default 90). 0/unset disables the purge, in which case evidence and working repositories are retained until the account is deleted.
• One-time credential deletion: enforced when a migration reaches done, failed or cancelled; for blocked migrations, at the retention sweep.
• Account deletion endpoint: DELETE /api/me (authenticated, self-serve).

8. Contact

Data-protection queries: legal@lastloop.com

Last Loop GmbH, Darwingasse 20/29, 1020 Wien, Austria — FN 676580x, Handelsgericht Wien. See also the Imprint, the Data Processing Agreement and the Terms of Service.

You have the right to lodge a complaint with a supervisory authority. The competent authority for us is the Austrian Data Protection Authority (Österreichische Datenschutzbehörde), Barichgasse 40-42, 1030 Wien, dsb@dsb.gv.at.

Odoo Migrator — Security Overview

Partner-facing security overview — the document your IT or security reviewer asks for. It describes controls that are actually implemented; it is not a warranty.

Service: Odoo Migrator — the custom-code half of an Odoo.sh upgrade,
automated with parity evidence.
Provider: Last Loop GmbH, Darwingasse 20/29, 1020 Wien, Austria (FN 676580x)
Last updated: 27 August 2026

What Odoo Migrator can and cannot touch

Can (least privilege, scoped to what you grant):

• Read your source code — on GitHub via a GitHub App installation token, on GitLab via the OAuth connection or the access token you supply for a self-hosted instance — only on the repositories you explicitly grant.
• Write exactly one branch (ll-migrate/<src>.0-to-<tgt>.0-<id>) and open one pull request (a merge request on GitLab). Nothing is merged.
• Read your login and installation/group list to scope everything to your account.

Cannot / does not:

• No access to your production database, live Odoo environment, or servers.
• No merges, no deploys, no writes to your default branch.
• No use of your code or data to train our models. The migration engine sends module source to the model provider listed under Hosting & sub-processors, which is contractually required not to train on it. [BLOCKING: confirm once the provider is pinned — see the sub-processor note below.]

Authentication & authorization

• Partner login: platform OIDC (ZITADEL, via the Lastloop control-plane auth gateway). Identity is a short-lived bearer token validated by the platform on every request — there is no session cookie and no per-service signing key for us to leak. Connecting a forge (GitHub/GitLab) is a separate, later step from signing in.
• Tenant isolation: each customer is a distinct platform workspace. Every migration, repository, credential and credit balance is scoped to that workspace, and per-request ownership checks prevent cross-account access.
• Repository scope: installations, groups and repositories are enumerated using your forge token, so you only ever see your own.
• Admin surface is gated to an explicit operator allowlist.

Data protection

• Encryption in transit: all external traffic over HTTPS/TLS.
• Encryption at rest: partner forge OAuth tokens, self-hosted GitLab access tokens, and one-time working-repository credentials are sealed with AES-256-GCM. One-time credentials are deleted when a migration completes, fails or is cancelled; a blocked migration keeps its credential so a retry can succeed, and it is removed with the working repository at the retention sweep.
• Secrets management: application secrets are delivered via a secrets sidecar and are never present in source code or deployment manifests.
• Retention & erasure: the mirrored copy of your modules and the migration evidence are both retained for a bounded window (default 90 days after the run reaches a final state), then purged automatically; account deletion purges them immediately. See the Data Retention Policy.

Integrity & platform hardening

• Webhook authenticity: GitHub webhooks are verified with a constant-time HMAC signature check; GitLab webhooks are verified with a constant-time comparison of the shared webhook token.
• Abuse controls: per-partner rate limiting on expensive endpoints plus a global concurrency limiter.
• Isolation: migrations run in isolated engine workspaces; source is mirrored in via one-time, per-run credentials, not long-lived tokens.
• Network policy: egress is restricted to declared destinations (GitHub, in-cluster services) via network policy.

Availability & operations

• High availability: the Service runs multiple replicas; background work (polling, batch promotion, retention) runs on a single elected instance via a database leader lock to avoid duplication.
• Crash recovery: an interrupted migration mirror-in is automatically resumed rather than lost.
• Observability: health checks and operational metrics (state counts, failures, and a stuck-migration signal) are exposed for monitoring.

Hosting & sub-processors

• Compute & database: EU hosting (Hetzner, Helsinki).
• Source & delivery: GitHub or GitLab, depending on where your repository lives. A self-hosted GitLab instance is your own infrastructure — we connect outbound to it with the token you supply.
• Identity & billing: the Lastloop platform (OIDC sign-in, workspace tenancy, credit balances), same EU cluster. Card payments for credit top-ups are processed by Stripe; we never see full card numbers.
• Migration engine model provider: [BLOCKING — must name a single pinned provider and its region before this document is published. See the sub-processor action note in the DPA: the engine currently reaches models through a proxy that can route to several providers, including some outside the EEA with no adequacy decision.]

Vulnerability management

• Dependency vulnerability scanning runs in CI (govulncheck) on every pipeline, so a vulnerable dependency is surfaced at the next change rather than on a calendar.
• We aim to remediate known-exploited or critical vulnerabilities affecting the Service promptly, and to pick up dependency and base-image updates in the ordinary release cycle. We do not offer a contractual patching SLA.

Reporting a vulnerability

Please report security issues to security@lastloop.com.

We welcome good-faith reports and will acknowledge them without undue delay. We ask that you give us a reasonable opportunity to remediate before public disclosure, and that you avoid accessing, modifying or deleting data that is not yours while investigating. We will not pursue legal action against researchers who follow that principle.

This overview describes current controls and is provided for information; it is not a warranty. See the Terms of Service and Data Processing Agreement for binding terms.