Self-hosted Customer.io alternative for EU data residency

Why a self-hosted Customer.io alternative for EU data residency changes the question

The main open-source option for an EU residency requirement is self-hosted Dittofeed, run in your own EU infrastructure, because it keeps the customer data store and journey engine under your control. The harder question is not the platform itself but the email and SMS providers it hands messages to, which remain a separate processing decision. Customer.io fixes the data region when the account is set up and does not migrate accounts between regions, so if your organization chose a region earlier, that choice now shapes every later option. Customer.io's EU region in Belgium is a hosted residency choice, and this page does not claim that it fails any requirement. Your task is to test whether it meets your own obligations and to compare that with what you would operate yourself.

The reader's first step is to map every place personal data goes today: the Customer.io workspace, the data pipeline that feeds it (such as Segment or the Dittofeed API), and each messaging provider. Under the GDPR, storage outside the EEA and remote access from a third country are both treated as transfers by the EDPB in Guidelines 05/2021 (version 2.0), so a support engineer viewing a profile from abroad can matter as much as a database location. Ask your vendor in writing which sub-processors touch EU data and where support access originates. Dittofeed says self-hosting keeps sensitive personal data inside the operator's own VPC, but you still need to confirm the same for each provider Dittofeed connects to, such as SendGrid or Amazon SES.

Plan for the legal exposure that remains even when storage is in the EU. The CLOUD Act provision at 18 U.S.C. 2713 applies to US-based providers regardless of where data sits, so the provider's corporate nationality belongs in your transfer assessment, following the approach in EDPB Recommendations 01/2020. If you rely on the EU-US Data Privacy Framework for any US processor, note that the adequacy decision is under appeal as Case C-703/25 P, so keep standard contractual clauses as a fallback. Decide early whether a self-hosted stack with EU-only processors is required, optional, or a benefit you want for lock-in and exit reasons, because that answer determines whether you need a migration plan at all.

What GDPR Chapter V and related rules require of messaging data

Moving messaging data to a self-hosted platform changes where personal data is stored and who can reach it, and EU transfer rules apply to both. The cards below set out the legal tests that decide whether a Customer.io replacement keeps profiles, events and message logs inside the EU, and what your own transfer assessment has to cover.

Article 44 covers onward transfers

Every transfer of personal data to a third country must meet Chapter V conditions, and that includes onward transfers made by your processors and their sub-processors. Messaging stacks often pass profiles and events through email, SMS and analytics vendors, so each hop needs mapping. Infringements of Articles 44 to 49 can draw fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). Ask every vendor in the chain where data is stored and where support staff can view it.

Remote access counts as a transfer

The EDPB's Guidelines 05/2021 state that remote access from a third country is a transfer, even when data is only displayed on a screen for support or administration. Storing data in a cloud outside the EEA is also a transfer. For a self-hosted messaging stack, this means vendor support engineers and offshore administrators can create transfers even when the database sits in an EU region. Check who holds administrative access and from where.

Schrems II and the Data Privacy Framework

The CJEU invalidated the Privacy Shield in Case C-311/18 on 16 July 2020 but held that standard contractual clauses remained valid. The EU-US Data Privacy Framework adequacy decision, Commission Implementing Decision (EU) 2023/1795, covers only US organizations on the Data Privacy Framework List, and an appeal in Case C-703/25 P is pending. Treat Data Privacy Framework certification as a fact to re-verify, not a permanent basis. Keep standard contractual clauses and a documented transfer impact assessment as fallback options.

US CLOUD Act reach

18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. A US-headquartered provider holding your EU messaging data may therefore receive a US demand. EDPB Recommendations 01/2020 say that where access goes beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Ask vendors whether they have received such requests and how they respond.

Confirm your own transfer assessment

These rules are applied case by case, and this page does not replace legal advice or your data protection officer's review. Document each flow from your application to email and SMS providers, state where each one stores and accesses data, and record the Article 46 safeguard relied on. Ask your counsel how Article 48 applies to any foreign court order, and whether the Data Act's switching and third-country access duties in Article 32 affect your provider contracts.

Where Customer.io's EU region meets the constraint and where it leaves questions open

Customer.io fixes the data region when the account is set up, and moving existing accounts between regions is not an option, so a team that needs EU residency must decide the region before it sends its first message. If the account already sits in the US region, the practical route is a new workspace in the EU region, a re-import of people and attributes, and a rebuild of segments, journeys and tracking. That is a migration in its own right, which is why the region decision belongs at the start of the project, not after go-live. The Customer.io EU region is hosted in Belgium, and it is the hosted option to compare against self-hosting.

Hosting location is only one part of the question. Sub-processors decide who else touches personal data, so ask Customer.io for its current list, the country each sub-processor operates from, and how changes to that list are notified. Ask also whether support access from outside the EU is possible, since EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen, as a transfer. Ask where backups are stored, how long they are kept, and whether they follow the EU region. Finally, request written third-country access terms: how the vendor responds to a foreign authority request, and whether it is bound by the contractual safeguards in Commission Implementing Decision (EU) 2021/914.

Do not treat any of these answers as an assumption about Customer.io's compliance status. Ask for the written answers, the data processing agreement and any current audit or certification documents the vendor is willing to share, and check them with your privacy and legal teams. Email and SMS providers are a separate question, because Dittofeed connects to them and they also process message content and recipient data, so the same sub-processor and region questions apply to them. The Data Act makes switching rights relevant here as well, since customers can move to on-premises infrastructure under Articles 25, 29 and 50 of Regulation (EU) 2023/2854, but the contractual exit terms still need to be read and confirmed in writing.

Which open-source options keep messaging data in your EU infrastructure

Dittofeed is MIT licensed and can be deployed inside an EU cloud account that your organization controls. According to Dittofeed's own repository, self-hosting keeps sensitive personal data inside the operator's own VPC, so the region you pick for the VPC, database and workers determines where profile and event data sits. Customer.io fixes its data region at account setup, while here you choose the region yourself and can keep the stack in one EU region.

Region selection: Pick an EU region for the compute, PostgreSQL-compatible database and any object storage, and confirm that backups and logs stay in the same region.
Network boundaries: Keep the Dittofeed API and dashboard behind private networking or a VPN, and restrict who can reach the database.
Operator control: Your team, not a vendor, decides when to upgrade and where data is copied.
Third-party exposure: Email and SMS providers receive message content and recipient addresses, so they remain a separate residency question.
Cloud provider access: Check the cloud provider's own transfer and government access terms against EDPB guidance before you choose a provider.

Confirm the region in writing with your cloud provider and map every service that stores event data.

Mautic and listmonk do not replace Customer.io's event-driven journeys, but they can cover adjacent needs in the same EU infrastructure. Mautic is licensed under GPL-3.0 or later and provides contact management, campaigns and CRM integration, including a documented Salesforce plugin. listmonk is an AGPL-3.0 newsletter manager shipped as a single binary with PostgreSQL. Keeping them in the EU avoids splitting audience data across regions.

Mautic scope: Use it for contact-centric marketing campaigns and imports from CSV, with background imports run through the mautic:import command.
listmonk scope: Use it for newsletters and mailing lists where a single binary and PostgreSQL keep operations small.
Overlap risk: Avoid keeping the same person in three systems without a clear source of truth.
Mail delivery: Both still need an email provider or an SMTP relay, which carries its own residency terms.
Licensing review: Have legal confirm how GPL and AGPL terms apply to any modifications you make.

Decide which system owns each audience before you migrate, and document that decision for your records of processing.

How to deploy Dittofeed in EU infrastructure under the constraint

This sequence maps every personal data flow and processor before any hosting decision, then builds Dittofeed and its database inside your EU boundary and proves that messages match Customer.io before you cut over.

Map every personal data flow and processor
The privacy or data protection lead and the platform owner list each source that sends profiles and events, each place Dittofeed will store data, and each third party that touches a message, including the email provider, the SMS provider and any support tooling with remote access. For each one, record where the data is stored, where it is accessed from, and whether any party outside the EU can view it on screen. EDPB Guidelines 05/2021 treat remote access from a third country, even display-only support access, as a transfer, so include administrator access paths in the map. The step is done when every flow has an owner, a location and a transfer assessment, and the map is signed off by the controller.
Choose EU hosting for the application and database
The platform team selects an EU cloud region or data center for the Dittofeed application and its PostgreSQL database, and confirms that backups, logs, snapshots and replicas are held in the same EU boundary. Ask the hosting provider in writing where each storage class lives, who can administer the control plane, and whether any support access originates outside the EEA. Because Dittofeed is designed to run inside the operator's own VPC, the platform owner should confirm that the network boundary, not only the region label, matches the data map. The step is done when a written hosting statement covers compute, database, backups and logs.
Deploy Dittofeed with Docker Compose or Helm
The platform engineers deploy Dittofeed on the EU infrastructure using the Docker Compose or Helm chart in the project repository, depending on the target platform. Pin a specific tagged image rather than tracking the latest build, because the project's recent GitHub releases are pre-release tags, and confirm the version you are running against the release notes. Store secrets in your existing secrets manager, restrict database access to the application network, and keep the deployment definition in git. The step is done when the instance starts, the database migrations complete, and the health checks pass inside the EU network.
Connect event sources through Segment, reverse ETL or the API
The data or integration engineers point existing event tracking at Dittofeed, using Segment, reverse ETL or the Dittofeed API as your current stack allows. Confirm that every source sends only the attributes the messages need, because each field you forward becomes personal data stored in your EU database. Check that the Segment or reverse ETL connection terminates inside your chosen architecture and that you know which vendor sees the raw events during transit. The step is done when test events arrive in Dittofeed, appear on the correct user profiles, and show the expected attribute values.
Select and verify the email provider
The messaging lead chooses an email provider that Dittofeed integrates with, such as SendGrid or Amazon SES, because Dittofeed connects to providers rather than sending mail itself. Ask the provider to state in writing where sending, logging and event data are processed and stored, whether it offers an EU processing region, and which transfer mechanism covers any residual transfer, such as standard contractual clauses under Commission Implementing Decision (EU) 2021/914. Also review whether the provider is subject to third-country access laws, since the EDPB says a controller should assess that exposure before engaging such a processor. The step is done when the provider's processing locations, sub-processors and transfer terms are recorded in your data map.
Configure SMS and other channel residency
The messaging lead repeats the residency check for each SMS, push and WhatsApp provider that will carry messages, since Dittofeed supports these channels and each one stores its own message logs and recipient numbers. Confirm the provider's data processing location, retention of message content and delivery records, and any sub-processors outside the EEA. Where a provider cannot commit to EU processing, record the transfer basis or decide to exclude that channel from the EU workload. The step is done when each channel has a documented processing location and transfer position, approved by the privacy lead.
Add backup, access control and logging inside the EU
The security and platform teams configure backups for the PostgreSQL database and application state with storage and keys held in the EU, define role-based access for administrators, engineers and marketers, and enable audit logging for template, segment and journey changes. Restrict administrative access to named accounts with multi-factor authentication, and confirm that log shipping and monitoring tools also keep data in the EU. Test a restore into a separate EU environment before relying on the backups. The step is done when a restore test succeeds, access reviews have a named owner, and audit logs show who changed a live campaign.
Run both systems until messages match
The marketing operations team runs Dittofeed and Customer.io in parallel, sending matching test journeys and comparing the content, recipients, timing and suppression behavior of each message. Keep Customer.io as the sending system of record until the results match across the agreed set of journeys, then switch sending and retire the old event tracking. Confirm the Data Act switching rights and any notice terms in your Customer.io contract before you give notice, and export your people, attributes and templates first, as described in the migration guidance. The step is done when the parallel comparison is signed off and the cutover date is recorded in the data map.

Where email and SMS providers still process personal data

Running Dittofeed in your own EU infrastructure keeps the journey engine and profile store under your control, but messages still pass through third-party providers. The cards below mark where personal data can still leave the EU, so you can ask each provider the right questions before you sign.

Email provider receives recipients and content

Dittofeed hands sending to an email service provider such as SendGrid or Amazon SES rather than sending mail itself. The provider receives recipient addresses, message content and, depending on configuration, tracking data for every message. Ask where the sending infrastructure and logs are stored, and whether the provider offers an EU processing location and which transfer mechanism covers any remaining transfer.

SMS provider receives phone numbers

SMS and WhatsApp delivery requires the recipient's phone number and the message text to reach a carrier or messaging provider that you select and contract separately. Phone numbers are personal data, and message text can reveal sensitive facts about a customer. Confirm the provider's processing locations, the carriers it routes through, and whether message content is retained and for how long.

Provider support and remote access

The EDPB's Guidelines 05/2021 treat remote access from a third country as a transfer, even when staff only view data on a screen for support or administration. Support engineers, follow-the-sun teams and incident responders at a provider may sit outside the EEA. Ask each provider which countries support staff access data from, and whether access to customer data is restricted by role and logged.

Sub-processor chains

Each provider relies on its own sub-processors for hosting, monitoring, logging and content delivery, and those sub-processors may be located outside the EEA. A transfer can occur at any link in the chain, and Article 44 applies to onward transfers as well. Request the current sub-processor list with locations, and confirm that your contract requires notice before changes.

EU processors under third-country law

EDPB Example 12 says that using an EU processor subject to third-country law with extraterritorial effect is not in itself a transfer. However, complying with a third-country authority request would be one, so the controller should assess that exposure before engaging the provider. The CLOUD Act reaches providers holding data under their control wherever it is stored. Ask the provider whether it has received such requests, how it responds to them, and what it commits to contractually.

Transfer mechanisms and the Data Privacy Framework

If a provider's support or storage falls outside the EEA, you need a valid transfer mechanism, such as the Commission's standard contractual clauses or an adequacy decision. The EU-US Data Privacy Framework applies only to US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Ask each provider which mechanism it relies on and whether a transfer impact assessment is available.

What a self-hosted Customer.io alternative for EU data residency involves

Does self-hosting Dittofeed alone satisfy EU data residency?

No. Running Dittofeed in your own EU infrastructure keeps the core customer data and journey logic under your control, but it does not by itself make every message path residency-compliant. Dittofeed integrates with email service providers such as SendGrid and Amazon SES rather than sending email itself, so those providers process recipient addresses and message content on their own systems. SMS and WhatsApp providers add another processing location. Under GDPR Article 44, any transfer to a third country, including onward transfers, must meet Chapter V conditions, and EDPB Guidelines 05/2021 treat storage in a cloud outside the EEA, or remote access from a third country, as a transfer. Map each provider's processing locations and sub-processors in writing before you sign, and confirm them with each vendor.

What does the hosting and migration work cost, by component?

The cost splits into components rather than one number. The Dittofeed license is free under MIT, so the spend goes to infrastructure (compute, a database, and backups in an EU region), email and SMS provider fees, the one-time migration of people, attributes, segments and journeys, and the engineering time to run the platform after go-live. Provider fees and infrastructure recur monthly, while migration and integration are one-time. Costs rise with the number of profiles and messages you send, the number of environments, the number of channels, and how much of your event tracking you repoint. Ask any implementation partner for a fixed-scope quote that lists each component, who pays for it, and which items recur. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list. See the Customer.io cost vs self-hosted Dittofeed comparison for the full breakdown.

How long does a Dittofeed migration take and what drives the timeline?

No duration is published for this work, so the timeline should come from a written scope rather than a general estimate. The main drivers are the number of journeys and segments to rebuild, how many event sources you must repoint through Segment, reverse ETL or the Dittofeed API, the number of channels and email providers to connect, and how long you run both systems in parallel until messages match. Data region setup and the approval cycle for your data protection and security reviews also affect the schedule. Ask for milestones that name each dependency, and check the detailed steps in the migration from Customer.io to Dittofeed guide before you agree a plan.

What does the migration need from our own team?

Expect to supply several people for the duration of the work. A product or lifecycle marketing owner must confirm which journeys and segments still matter. Engineers who own your event tracking must agree how events reach Dittofeed, whether through Segment, reverse ETL or the API. A security or privacy lead must review the data flow, the provider processing locations and the transfer assessment. Someone must also approve the export of people and attributes, and decide how sensitive fields are cleared before any data is shared. Your team will also own sign-off on the parallel run, when old and new messages are compared. Agree these responsibilities in the scope so that delays on either side are visible early.

Can our own engineers host and migrate Dittofeed without a partner?

Yes, it is possible if your team has the skills in-house. Dittofeed documents Docker Compose and Render deployments, and provides Helm charts in its repository, so a capable platform team can start a test environment without outside help. The harder parts are the production work: securing the EU infrastructure, backing up the database, integrating email and SMS providers, rebuilding journeys, running a parallel period, and documenting the controls that your compliance assessment will ask about. Consider what happens after go-live, including upgrades, which come as pre-release tags. Decide whether your team can carry that workload for the life of the system. DeployOpen can plan, implement, harden, back up, upgrade and document the platform, and offers ongoing support as a retainer.

Is an alpha-stage open-source project suitable for regulated personal data?

It can be, but only after a deliberate risk decision. Dittofeed's recent GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, so the project is still changing quickly. For regulated personal data, check the release state at the time of decision, pin a specific version, test upgrades in a non-production environment, and record your acceptance of the residual risk. Ask whether the vendor or a partner can provide upgrade paths, security fixes and support in writing. A supported deployment should also include backups, access controls and logging that your auditors can review. Compare this with the support terms in the Customer.io vs Dittofeed comparison before you choose.

Which transfer risks remain if the data sits in an EU region?

Storing data in an EU region removes one transfer path, but it does not remove every exposure. EDPB Recommendations 01/2020 state that where a cloud provider must access data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure is envisioned. The US CLOUD Act, at 18 U.S.C. 2713, can require a US-based provider to preserve or disclose data in its possession, custody or control wherever that data is located. Assess whether any provider in your chain is subject to such powers, and document your reasoning. GDPR Article 83(5)(c) sets fines of up to EUR 20 million or 4% of worldwide annual turnover for infringements of Articles 44 to 49. Your legal counsel should own this assessment, and DeployOpen prepares the technical evidence for it but does not issue legal opinions or certifications.

Evidence regulators and auditors ask for on messaging data residency

Moving customer messaging into your own EU infrastructure only helps if you can show where personal data sits, who else touches it and on what legal basis it moves. The five items below are the records a supervisory authority or auditor typically asks to see, and each one depends on the others. DeployOpen prepares these controls and evidence, but independent auditors and certification bodies issue any audit report or certification.

Record of processing and data map

The Article 30 record and a data map should list every system holding profiles, events, templates and delivery logs: the Dittofeed database, the Segment or reverse ETL feeds, the email and SMS providers and any backups. For each location, record the purpose, the categories of personal data and the retention period. Check the map against actual network flows, not the architecture diagram, because a forgotten log shipper or support tool is the most common gap.

Transfer impact assessment and Chapter V basis

Every transfer to a third country, including remote access from outside the EEA for support, needs a documented Chapter V mechanism. Where a provider still transfers data to the United States, the assessment should name the mechanism, such as standard contractual clauses under Commission Implementing Decision (EU) 2021/914, and explain why it is effective. Check whether the provider's Data Privacy Framework certification is relied on, and track the pending appeal in Case C-703/25 P before treating that reliance as stable.

Processor contracts and sub-processor lists

Each email, SMS and hosting provider acting for you needs a written processor contract under Article 28 that covers instructions, confidentiality, security and deletion at exit. Request the current sub-processor list from every vendor, record where each sub-processor operates and confirm that you receive notice of changes. For self-hosting, the cloud or data center provider is also a processor, so its contract belongs in the same file.

Provider processing location documentation

Ask each messaging provider in writing where message content, recipient addresses, delivery events and logs are stored and processed, including backup regions and support tooling. Email and SMS providers often process data outside the EU even when your account is in Europe, so the answer must cover the whole delivery path. Keep the written answers with their dates, since locations change and a stale answer will not satisfy an auditor.

Access logs and key management inside the EU

Keep administrator access logs, database audit records and key management records within the EU boundary you have defined, and confirm that log shipping and monitoring services do not copy personal data abroad. Document who holds decryption keys, where they are generated and stored, and how access is revoked. Test that a support engineer working from outside the EU cannot view personal data without the access being recorded and approved, because remote viewing counts as a transfer.

How the Data Act's switching rights apply to leaving a hosted messaging service

The EU Data Act gives customers of a data processing service the right to switch to another provider or to on-premises ICT infrastructure, which is the right that matters if you want to move messaging data out of Customer.io's Belgium region and into your own EU infrastructure. Under the Regulation (EU) 2023/2854, the switching rights apply from 12 September 2025, the maximum notice period you can be asked to give is two months, and the transition period is 30 days. From 12 January 2027, providers may no longer charge switching fees. Confirm with your vendor in writing how these terms map onto your current Customer.io contract, including whether your plan is treated as a data processing service and what exit assistance, export formats and deletion steps the contract specifies.

The right is most useful for residency planning if you start the clock early. Build a dated exit plan that lists the people and attributes you need to export, the event streams that feed the account, and the email and SMS providers that send on your behalf. Ask the vendor which export files it will provide, whether the export contains data outside the EU region, and how deletion is confirmed after cutover. Keep in mind that a switch does not, by itself, settle where your sending providers process data, so the provider questions in the sections above still apply after you leave.

For a fuller walkthrough of the steps, see the migration guide for moving from Customer.io to Dittofeed. Treat the Data Act timelines as a contractual baseline rather than a guarantee of how quickly your own cutover will complete, because the transition runs alongside your engineering, testing and sign-off work. Record the vendor's written answers, the export dates and the deletion confirmation in your transfer file so that your data protection officer can show how the move was managed.

Confirm these points before you choose a region or provider

Start by writing down exactly which data leaves your control and where it is processed. For a Dittofeed deployment, that means the user profiles and attributes, the event stream arriving from Segment, reverse ETL or the Dittofeed API, the message templates, and the logs. Confirm which of these contain personal data, which contain only identifiers, and which must stay inside your own VPC. Then confirm the location of every component that touches them: the database, the workers, backups, and the monitoring stack. A region choice only holds if each of these sits in the EU or in a country your transfer analysis already covers. Keep the inventory in writing, because it becomes the basis for your records of processing and for any transfer assessment your data protection officer needs to sign off.

Next, obtain the processing terms from every email and SMS provider you plan to connect. Dittofeed integrates with providers such as SendGrid and Amazon SES rather than sending mail itself, so the message content, recipient addresses and delivery metadata pass through those services. Ask each provider where it stores and processes this data, which sub-processors it uses, whether support staff in a third country can view message content, and what contractual transfer mechanisms it offers. Also ask Customer.io for its written statements on sub-processors and on support access, since the current account still holds your data until you migrate. Compare those answers against the EDPB guidance on remote access and cloud storage, which treats a viewer in a third country as a transfer. Record the dates of each statement, because provider terms change.

Finally, decide whether an alpha-stage release can meet your internal support needs. The latest Dittofeed releases on GitHub are pre-release tags, so confirm with the maintainers how breaking changes, security fixes and upgrade paths are communicated, and whether your team can absorb an upgrade on short notice. Decide who owns patching, on-call response and restores, and whether that work sits with your staff or with an external partner. If you need these answers in a written form, DeployOpen plans, implements and hardens self-hosted platforms under a fixed scope with agreed deliverables and timelines, and it can run an assessment of your data flows, provider terms and support model before any decision is made. Ask for that scope in writing before you commit.

How DeployOpen deploys messaging platforms under EU residency constraints

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For an EU residency project, that means mapping where personal data is stored and processed before any platform is chosen, then building the messaging stack in the region the organization controls.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Scope maps every place profile data, events and message content will sit, including email and SMS provider hops.
Written scope names the regions, accounts and sub-processors that the EU residency review must cover.
Quotes follow from the written scope, and the scope lists which cost components the client will carry.

How we build

Dittofeed is deployed in the client's own EU infrastructure, with the database, workers and event ingestion kept in-region.
Helm charts or Docker Compose are configured to the client's network, secrets handling and backup standards.
Email and SMS provider connections are set up with documented regions and data processing terms the client has reviewed.
Campaign templates and journeys are kept under version control, with tests run in CI before anything is sent.

How we hand over

Handover includes architecture documentation showing data flows, storage locations and third-country access points.
Operational runbooks cover upgrades, backups, restores and rotation of provider credentials.
Evidence for compliance assessments is prepared, though independent auditors and certification bodies issue any reports.
Clients receive a list of open items, such as alpha-stage release risks, for their own risk acceptance.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover tracking the project's pre-release tags and testing each upgrade in a staging environment first.
Periodic security testing of applications and APIs can be scheduled alongside platform maintenance.
Ask us to confirm the support boundary, response arrangements and upgrade process in the written scope.