Request & review
First, define the company, participants, source, destination and scope. Switona independently checks the company, authority and company contact.
How Switona protects a switch: verified authority, private storage, controlled processing and documented deletion.
Switona processes data for a specific, authorized switch. A provider can initiate a case. That does not grant permission to access or transfer company data.
First, define the company, participants, source, destination and scope. Switona independently checks the company, authority and company contact.
The verified contact receives an email, even without an account. After signing in and verifying a second factor, they sign the digital mandate. Switona reviews it again before enabling data preparation.
Authorized files are stored privately. The application analyses structure and types, suggests mappings and reports simulation errors. Only explicitly configured connections are used.
The exact transfer requires another company approval. Downloading a package is not proof of a destination import. Temporary files are removed after the selected period; evidence has separate retention rules.
Access depends on organization, role, case participation and valid company authorization. The API checks these conditions on the server, supplemented by database access policies. A self-declared company name, email address or uploaded document is insufficient.
Internal reviewers cannot appoint themselves or approve their own requests. Sensitive approvals require a fresh second factor. Scope or destination changes can invalidate approvals. Rejection or revocation blocks further operations that require authorization; it cannot retrieve data already transferred into another system.
The production Supabase database and private file storage are configured in Frankfurt (eu-central-1). The server-side Next.js application on Vercel is configured for Frankfurt (fra1). Public website content is served through Vercel’s delivery network.
Vercel, Supabase and Resend are international service providers. An EU region does not mean that all support, security logs, email delivery and subprocessors operate exclusively within the EU. Processing terms, recipient countries and transfer mechanisms require a separate assessment. We do not make a blanket promise of exclusively European processing.
The application uses HTTPS. Both migration files and authority evidence are stored in private buckets. Migration downloads pass through an authenticated server request with a fresh authorization check. Storage encryption at rest follows the respective infrastructure provider’s security measures.
API credentials receive additional AES-256-GCM encryption; the key stays on the server and is not delivered to the browser. REST connections require HTTPS and are checked against internal network destinations. This is not end-to-end encryption: the application must process authorized data to validate and transform it.
Choose temporary migration data retention in the case: immediately, 24 hours, 7 days or 30 days after completion. Scheduled cleanup removes source files, result packages, temporary configurations and plans. Completed deletion is recorded. The deadline triggers cleanup; it is not a guarantee of deletion at an exact second.
Accounts, company information, digital mandates, security and migration evidence, and reusable organization profiles are outside that file retention period. Active or abandoned cases also need a separate deletion decision. Provider backups and copies already downloaded or transferred have their own rules. Binding periods for these categories must be established in the processing arrangement.
No external AI service is currently connected to migration processing. Suggestions use semantic rules, field names, types and saved mappings. No arbitrary or model-generated code is executed.
Reusable mappings stay within the organization. Raw records are not added to a shared training archive. Any future external model integration must first define its purpose, data scope, provider and processing terms transparently.
GDPR requires a lawful basis, clear purposes, data minimization, storage limitation and appropriate security, among other obligations. Company approval authorizes the assignment technically and operationally. It does not replace a lawful basis for processing personal data or information owed to data subjects.
The company must determine which data it may transfer and why. Where Switona processes it on instructions, processing terms must cover subprocessors and technical and organizational measures. EU hosting or provider certifications do not constitute a GDPR certification of Switona itself.
Data scope, lawful basis, destination access, processing terms, international transfers, retention and evidence periods must fit the actual use. Special-category data and sector-specific obligations need a separate review.
The digital mandate records the declaration, case and timestamps. It is not a qualified electronic signature. The EU Data Act may apply to switching data processing services, but does not give blanket permission to transfer personal data. Switona supports technical delivery and does not replace a legal assessment of the individual case.
Requests, technical connection data and processing needed for the case; application region Frankfurt.
Provider processing terms ↗Accounts, organization and case data, migration files, evidence and encrypted API credentials; project region Frankfurt.
Provider processing terms ↗Recipient address, authorization message including company, source, destination and confirmation link, plus delivery status. No migration files attached.
Provider processing terms ↗Updated 29 September 2026. This page describes the technical implementation. See the privacy notice for controller information, data subject rights and website processing.
Choose where you go next. We'll help your data get there.