Beebole Material Service Change & Platform Migration Addendum
This Addendum supplements, and is incorporated by reference into, the Beebole Terms of Service (“ToS”). Capitalised terms not defined here have the meaning given in the ToS. In the event of a conflict between this Addendum and the general ToS with respect to a Migration governed by this Addendum, this Addendum controls for the duration of the applicable Migration window.
Beebole operates two service platforms in parallel during a coexistence period of approximately one to two years. This Addendum explains what counts as a Material Service Change, how the two platforms coexist, how a customer’s data-residency region is determined and guaranteed, and the rights and protections that apply if and when a customer moves from V1 to V2.
V1 (legacy): Customer Data hosted on Linode (EU); payments processed via Adyen.
V2 (new): Customer Data hosted on Google Cloud — on an EU server for EU companies and a US server for US companies; payments processed via Stripe (EU-hosted).
V2 does not replace V1 on a single cutover date. Both platforms run concurrently. New customers are provisioned on V2. Existing V1 customers are offered the opportunity to move to V2 but are never moved automatically: migration is voluntary and requires the customer’s active acceptance (see §3).
1. Definitions
1.1 “Material Service Change” means a change by Beebole to the underlying delivery of the Services that materially affects the hosting, processing, or security posture of Customer Data, including:
(a) a change of hosting infrastructure or hosting sub-processor (e.g. Linode → Google Cloud);
(b) a change of payment processor (e.g. Adyen → Stripe);
© a change in the data-residency region in which Customer Data is stored or processed; or
(d) a change to the fundamental architecture of the Services that alters how Customer Data is stored, segregated, or accessed.
Routine maintenance, bug fixes, security patches, and feature additions that do not affect any of (a)–(d) are not Material Service Changes.
1.2 “V1” and “V2” have the meanings given in the introduction above.
1.3 “Migration” means the move of an individual customer’s account and Customer Data from V1 to V2.
1.4 “Migration window” means the period beginning when an individual customer’s Migration starts and ending when that Migration completes (including any rollback).
2. Coexistence rules
2.1 Parallel operation. During the coexistence period, V1 and V2 operate concurrently. A customer is served by exactly one platform at any given time. New customers are provisioned on V2; existing V1 customers remain on V1 unless and until they voluntarily migrate under §3.
2.2 Data-residency region determination. A customer’s data-residency region is determined by the customer’s company location:
EU companies → EU server (Google Cloud, EU region under V2; Linode EU under V1).
US companies → US server (Google Cloud, US region under V2).
Both V2 regions are operated on Google Cloud. The region applicable to a customer is recorded at provisioning and on Migration.
2.3 Residency guarantee. Beebole guarantees that a customer’s Customer Data is stored and processed in its elected region for the duration of the subscription. In particular, EU customers’ Customer Data does not transfer to the United States under V1 or V2. Any change to a customer’s residency region is itself a Material Service Change under §1.1©.
2.4 Residual transfer surface. The only EU→US data-transfer surface is (i) legacy US-hosted logs and audit trails and (ii) the Customer Data of US companies (which is intentionally stored on the US server). This does not affect the EU residency guarantee for EU customers’ Customer Data in §2.3.
3. Voluntary migration (V1 → V2)
3.1 Migration is optional and opt-in. Beebole will offer existing V1 customers the opportunity to migrate to V2. No customer is migrated unless and until that customer actively accepts the offer. Beebole does not treat silence, inaction, or the passage of time as acceptance, and does not migrate any customer by default.
3.2 Customers who decline remain on V1. A customer that does not accept a migration offer simply remains on V1. There is no penalty, no forced cutover, no deadline, and no obligation to move. Beebole expects to keep V1 in operation for approximately one to two years and may continue to operate it for as long as it reasonably chooses to do so.
3.3 Per-customer scheduling. Where a customer accepts, Migration is performed individually for that customer on a mutually workable schedule. Acceptance by one customer has no effect on any other customer, and coexistence continues for customers who have not migrated.
3.4 Data-integrity commitment. For the duration of an accepting customer’s Migration window, Beebole commits to migrate that customer’s Customer Data without loss or corruption and to verify data integrity on completion. For that Migration window only, this commitment overrides the general ToS disclaimer that Beebole does not warrant that it will preserve Customer Data without loss or corruption. Outside the Migration window, the general ToS terms continue to apply.
3.5 Service continuity and expected downtime. Beebole will design each Migration to minimise interruption. The expected maximum downtime for an accepting customer’s Migration will be stated to that customer in advance. Migration-related downtime is handled under the enhanced migration-period SLA terms in §4 and is separate from the standard maintenance cap.
3.6 Rollback. If a Migration fails or data-integrity verification does not pass, Beebole will roll the customer back to V1 and restore service on the legacy platform before any subsequent re-attempt.
3.7 Legacy-data retention and deletion. Following a successful Migration, Beebole will retain the customer’s legacy V1 data for 90 days to support verification and rollback, after which the legacy V1 copy is securely deleted. This 90-day legacy-retention period is specific to Migration and is independent of the standard retention periods in the Privacy Policy and DPA.
4. Migration-period SLA note
During an accepting customer’s Migration window, the following enhanced terms apply and take precedence over the corresponding standard SLA terms (see SLA):
Enhanced notice: Beebole will give at least 72 hours’ advance notice of any scheduled downtime within the Migration window (greater than the standard maintenance notice).
Dedicated downtime windows: Migration downtime occurs in dedicated, pre-notified windows that are separate from, and do not count against, the standard 8-hour-per-month scheduled-maintenance cap in the SLA.
Outside the Migration window, the standard SLA (including the 99.9% uptime commitment and the 8h/month maintenance cap) governs without modification.
5. Future end-of-life of V1 (conditional)
The protections in this section apply only if Beebole later decides to retire V1 entirely (a future end-of-life event). They are not part of the voluntary migration described in §3 and have no application for as long as V1 continues to operate. As of the effective date of this Addendum, Beebole has set no end-of-life date for V1.
5.1 Prior notice. If Beebole decides to retire V1, it will give affected V1 customers at least 60 days’ prior written notice before V1 is withdrawn. The notice will state the planned withdrawal date and the options available under §5.2.
5.2 Customer options on end-of-life. A customer that receives an end-of-life notice may, before the stated withdrawal date, choose to:
(a) migrate to V2, with the data-integrity, rollback, and migration-period protections in §§3.4–3.7 and §4 applying to that Migration; or
(b) terminate the affected subscription and receive a pro-rata refund of prepaid fees for the unused portion of the then-current subscription term.
5.3 No silent migration. Even in an end-of-life scenario, Beebole will not migrate a customer to V2 without that customer’s acceptance under §3.1. A customer that neither accepts migration nor terminates by the stated withdrawal date will have its subscription terminated with the pro-rata refund described in §5.2(b).
6. Relationship to the Terms of Service
This Addendum supplements and is incorporated by reference into the ToS and forms part of the agreement between Beebole and the customer. Except as expressly modified here for the duration of a Migration window, all terms of the ToS remain in full force and effect.