How to export your data from Optimizely before the contract ends
If a renewal, a price change or a data residency review is forcing an exit from Optimizely, start with the Experimentation Events Export, which is the main documented route for event data. As currently described, it delivers daily Parquet files and keeps them for one year, so the history you can take out is bounded by that window and by the date you start pulling it. Flag and experiment configuration does not arrive in those files and needs its own capture before the contract ends. Event-level experiment data and the configuration you record yourself are what can realistically leave. Anything not listed in the current export documentation should be treated as not exportable until Optimizely confirms otherwise in writing. Every export path, format and date in this section must be checked against Optimizely's current documentation before work starts, because no Optimizely source has been reviewed for this page.
Configuration is the part teams most often underestimate. Capture each feature flag with its default value, environments, targeting rules, rollout percentages, audiences and the variations it can return. Do the same for every experiment, recording its hypothesis, traffic allocation, status, primary metric and final decision. Store the snapshot with dates and named owners in your own repository, because it becomes the reference you rebuild against. Ask Optimizely in writing whether a bulk configuration export exists for your product lines, and whether the Experimentation Events Export covers both Feature Experimentation and Web Experimentation. Storage is also a residency question: confirm the S3 delivery end date of November 30, 2026, and the rule that EU customers deliver to Google Cloud Storage, before you build any pipeline.
Set the export start early and treat the one-year retention as your deadline for historical data. Put the renewal date, the notice period in your contract and the export window on one calendar. Then run a test pull, compare row counts and schema against a sample of experiments you know well, and confirm that the files open in your analytics stack. Agree the destination and retention policy with your data protection lead, since the files contain user identifiers and event data that may be personal data under your jurisdiction. Decide early whether migrated history will be re-analyzed or simply archived, because that choice determines how much of the Parquet data needs transformation. Keep a written record of what was exported, when and from which account, so auditors and future teams can trace the source of any result.
Which Optimizely data can you export, and in what format
This table compares each Optimizely data type with its export method, format, delivery target and limits. Rows marked as needing confirmation depend on details that Optimizely's current documentation must settle before you plan the cutover. Treat the experimentation events export as the only route with a confirmed schedule and retention window.
| Data type | Method and format | Delivery target | Limits and what to confirm |
|---|---|---|---|
| Experimentation events | Daily export in Parquet format | S3 delivery ends November 30, 2026. EU customers receive delivery to GCS only. | One-year retention. Confirm the field list, file layout and backfill options in Optimizely's documentation. |
| Flag and experiment configuration | Confirm whether a supported export or API route exists | Confirm the target format and where files or responses are delivered | Confirm which fields are returned, including targeting rules, rollouts and variation values. |
| Experiment results and decisions | Confirm whether results export separately from raw events | Confirm the delivery target and format | Confirm whether statistical outputs and decision history are included or must be rebuilt. |
| Audiences, events and metric definitions | Confirm whether definitions are exported or only referenced in events | Confirm the delivery target and format | Metric and audience logic may need manual recreation in GrowthBook. Confirm what is documented. |
| Web Experimentation data | Confirm whether the events export covers Web Experimentation as well as Feature Experimentation | Confirm the delivery target and format | Visual changes and snippet-based variations may not export as code. Confirm before planning. |
| Data before the one-year window | Not covered by the daily events export | Confirm whether a separate archive exists | Anything older than the retention window must be exported before it expires. Confirm the cutoff date with Optimizely. |
What does not leave Optimizely, and the workaround for each gap
A daily events export carries exposure and event records, but it does not hand over everything that defines your Optimizely program. The cards below cover the items that stay behind, the workaround for each, and what to confirm with Optimizely before the contract ends.
Events older than retention
Events beyond Optimizely's retention window are not in the export you receive today, so any analysis of earlier experiments depends on what you saved while it was still available. Start a continuous archive of the daily export on the first day of the contract, writing files to storage you control with a fixed folder layout by date and experiment. Confirm with Optimizely the retention period for each event type, whether historical backfills are available on request, and the delivery route that applies to your region. Missing days in the archive cannot be recovered later, so check them weekly.
Results and statistical outputs
The events file holds raw exposures and conversions, but it does not reproduce Optimizely's results pages, confidence intervals, or the decisions recorded against each test. Export the results tables and per-experiment summaries as files and store them with the metric definitions, audience settings, and start and stop dates used at the time. When you rebuild analysis in GrowthBook, recompute metrics from your warehouse and compare them with the archived results before cutover. Confirm which result exports Optimizely offers and whether they include the statistical method used.
Visual editor and page code
Web experiments built in the Optimizely visual editor store their changes as editor edits, along with any custom JavaScript and CSS attached to each variation. These edits do not appear in the events file, and they do not move into another tool automatically. Record each variation's code and editor changes as text in a version-controlled repository before the contract ends, including the page targeting rules and activation conditions. Confirm with Optimizely whether project or experiment configuration can be exported, and which parts exist only in the editor.
Users, roles and permissions
Accounts, project roles, and environment permissions are part of the Optimizely administration settings, and the events file does not include them. The new platform needs its own accounts and access model, so the old role structure is useful only if you document it. Inventory every user, group, role, and environment grant in a spreadsheet with the owner of each project and the approval rules that applied. Confirm with Optimizely whether user and role lists can be exported, and whether single sign-on configuration needs to be recorded separately for the replacement.
Audit history
Change logs that show who edited a flag, paused an experiment, or changed a targeting rule are an administrative record, and they are not part of the experiment events export. Losing them removes the trail that auditors and internal reviewers often ask for when they test change management. Export the audit log for the full contract period while the account is still active, and store it with a hash or checksum so later edits can be detected. Confirm with Optimizely the format and retention of audit logs, and whether the log can be downloaded by a user with the right role.
SDK keys and environment credentials
SDK keys and environment identifiers tie your applications to Optimizely projects. They do not carry over to another platform, and each application must be changed to use the new keys during cutover. Map every SDK key to the application, environment, and deployment that uses it before migration starts, so no service is left pointing at a retired key. Confirm with Optimizely how long existing keys remain valid after the contract ends, and whether any key can be rotated early to limit the time two systems run in parallel.
The export sequence, from inventory to a verified archive
This sequence turns Optimizely's events export and your current configuration into a verified archive you can use after the contract ends. Each step ends with a check you can run, so you know what you hold before any cutover or cancellation decision.
Inventory flags, experiments, metrics, audiences and users
The workspace owner or an experimentation lead lists every feature flag, experiment, metric, audience and user or seat record in Optimizely, noting status (active, paused, concluded) and owner. Keep the list in a spreadsheet or ticket so it can be reviewed later. Verify by comparing per-type counts with what the Optimizely console shows for each project and environment. Any gap is resolved before you move on.
Confirm the storage target and region rule
Confirm where the events export will be delivered. Optimizely's documentation states that S3 delivery ends on November 30, 2026 and that EU customers must use Google Cloud Storage, so an EU account on S3 needs a move before that date. Confirm the destination bucket, its region, retention settings and access grants with your cloud team. Verify by checking the bucket configuration and the export settings in Optimizely match each other, and that the bucket policy is recorded in your change log.
Start the daily events export and check the first delivery
Enable the Experimentation Events Export so that daily Parquet files are written to the storage target. Ask Optimizely to confirm the file layout, naming and schema for your account, since these details come from its current documentation. When the first delivery lands, open a few files with a Parquet-capable query engine and confirm the columns and row counts look right. Verify the first day's files are present and readable before you rely on the feed for any archive.
Capture configuration in a documented format
Record each flag's definition, variations, targeting rules, rollout percentages, and each experiment's hypothesis, traffic allocation, audience, primary and secondary metrics and dates. Store these as version-controlled YAML or JSON files, with a short README explaining the fields. Verify by asking a colleague who did not write the files to rebuild one experiment from its record alone. If they cannot, add the missing fields and repeat the check.
Archive results and decisions
For every concluded experiment, save the final results summary, the decision taken (ship, revert, iterate or inconclusive), the decision date and the approver. Store these in a shared archive with access controls that match your data classification. Verify by confirming that every concluded experiment in your inventory has a matching decision record and that each record links to its configuration file.
Reconcile counts and sample records
Pick a fixed date range and compare exposure counts per experiment and variant in the exported Parquet data with the numbers Optimizely reports for the same window. Then pull a random sample of raw event records and trace them back to the experiment and user identifiers they reference. Verify that every difference is explained and written down, such as time zone boundaries or late-arriving events. Unexplained gaps mean the archive is not yet complete.
How to check the export is complete before you rely on it
Treat the export as unverified until you have reconciled it against Optimizely's own reporting. Start by comparing event counts per day and per experiment for the same date range you pulled from the Experimentation Events Export, using the experiment results views in Optimizely as the reference. Expect small differences: bot filtering, late-arriving events, timezone boundaries in the daily partitions and attribution rules can all shift counts, so write down the tolerance you will accept for each experiment before you compare, and record every day or experiment that falls outside it. A gap concentrated on a single day usually points to a delivery or partitioning problem, while a steady gap across all experiments usually points to a definition difference that you need to document rather than fix.
Next, sample individual records and check them by hand. Pick a handful of events per experiment and confirm that the user or visitor identifier, variation or decision fields, event names, values and timestamps match what Optimizely shows for the same visitor. Check timestamps for timezone handling, since a one-hour or one-day offset will quietly move events into the wrong experiment window. Then reconcile configuration separately: every active flag, rule and experiment in Optimizely should have a matching record in your configuration capture, with its key, environment, status, targeting and variation names. Any item without a match is a gap in your exit inventory, and it should be resolved before the contract ends, not after.
If you plan to move to GrowthBook, add a destination check. The exported events must be loaded into the warehouse that GrowthBook will query, and GrowthBook only needs read-only SELECT access to that warehouse, so confirm that the service account can read the loaded tables and nothing else. Run your metric definitions against the loaded data, then compare the resulting experiment statistics with the Optimizely results for the same experiments before cutover. Do not expect zero difference. Two platforms will apply different statistical engines and metric definitions, so agree in writing which differences are acceptable and which would block the switch.
Export steps differ by storage target and region
If your Optimizely events already arrive in an Amazon S3 bucket, the work is a move of the delivery target, not a new export design. S3 delivery ends on November 30, 2026, so schedule the switch and backfill the history you need before that date. Keep the S3 feed running until the new destination has received and validated a full set of daily files.
- Confirm the cutover path: Ask account management which delivery options your contract supports and whether a parallel run is allowed.
- Backfill inside the one-year window: Export history you want to keep beyond one year into your own store before it ages out of the Optimizely export.
- Validate files and schema: Compare daily Parquet files, row counts and column definitions between the old bucket and the new target for several days before retiring the S3 feed.
- Move to a bucket you control: Create the target in your own cloud account with encryption at rest, a bucket policy that blocks public access and read access limited to named analytics roles.
Before cutover, confirm with account management the last date on which S3 files will be written for your contract and whether any files arrive after November 30, 2026.
EU customers must deliver export data to Google Cloud Storage, so an S3 path is not an option for this group. Start with a bucket in a Cloud Storage location that meets your residency commitments, then set up delivery with Optimizely, then validate the first files. Treat the GCS bucket as the system of record for export data and keep every downstream copy inside the same jurisdiction.
- Choose the location first: Pick a bucket location that matches your data residency commitments and record it in your data inventory before requesting delivery.
- Confirm the delivery setup: Ask account management to confirm the GCS destination, the file format and how the service identity and its credentials are managed.
- Apply least privilege: Grant the export identity write access to the one bucket it needs, avoid project-wide roles and limit read access to named groups.
- Check key control: If your policy requires control of encryption keys, confirm with your cloud team whether customer-managed keys can cover the bucket and every downstream copy.
- Set a bucket retention rule: Apply a retention policy or object holds that follow your own schedule, so you do not depend on the one-year window in Optimizely.
Confirm with account management that EU data is written to GCS and that no S3 delivery remains active for EU data after the switch.
If you have no cloud storage target for export data, the first decision is where the files will live, not a setting in Optimizely. Choose a platform you control, either a cloud account or your own object store, and define access, encryption and retention before the first file arrives. Pull at least one full day of data end to end to confirm the storage path works before any other export depends on it.
- Name the owner: Assign a team to own the bucket, its costs and its incident response, and confirm the store sits inside your residency boundary.
- Enforce encryption and access: Require encryption at rest and encrypted transfers, use role-based access with named groups and log reads and writes.
- Write your own retention rule: Decide how long raw Parquet files, transformed tables and experiment snapshots must be kept, since the one-year window in Optimizely is not your retention policy.
- Consider self-hosted object storage: If the data must stay on your own servers, evaluate S3-compatible stores such as Ceph RADOS Gateway, SeaweedFS or Garage and confirm they accept the delivery method you choose.
- Ask what the export can target: Confirm with account management which destination types your contract supports before you build anything.
Before you stop any other export, run a full daily delivery, restore one file and confirm that you can query it.
What to plan before renewal or termination
Leaving Optimizely is mostly a scheduling problem. The export window, the contract terms and the parallel run all depend on dates that only your contract and account team can confirm, so settle them first. Each card below is a decision or check that feeds the rest of the exit plan.
Confirm notice and renewal dates
Ask your account team for the notice period, the renewal date and the date your access ends in writing. Do not work from memory of a previous renewal, because plans and terms change at each one. Record the dates in the migration calendar and assign one owner to watch them. Every other step in this plan depends on that date.
Start the events export early
The daily Parquet Experimentation Events Export keeps data for one year, so history you do not pull in time can be lost. Start the export well before termination and confirm with your account team which delivery path applies to your account. If you are an EU customer, confirm the storage destination rules before you set anything up.
Write down what the contract allows
Create a written list of the data and configuration the contract lets you export, including experiment results, flag definitions, audiences and metrics. Ask whether anything is excluded, such as raw data, user-level records or archived experiments. Share the list with your legal and procurement teams so the scope is agreed before the exit begins.
Check deletion terms and timing
Find out what happens to your data after termination, including when deletion starts, how long it takes and whether you can request a deletion certificate. Confirm whether the vendor keeps backups and for how long. Make sure every archive you need is complete before the account is closed, because you may not be able to recover it afterward.
Run the replacement in parallel
Keep Optimizely and the replacement running side by side for a period long enough to compare flag evaluations and experiment results. Use the exported events to check that the new setup reproduces past results before cutover. A parallel run exposes gaps in tracking or metrics while the old platform can still answer questions.
Name who signs off the archive
Decide in advance who approves the final archive as complete, usually a named product owner with a second reviewer from security or compliance. Define what the sign-off covers, including checksums, file counts and a sample check of experiment results. Keep the signed record with the contract documents, since auditors often ask how historical experiment data was retained.
Questions teams ask before exporting their Optimizely data
Can we export our Optimizely data ourselves, or do we need a consultant?
Yes, a capable internal team can do much of the work, but the answer depends on who owns the Optimizely account, how many experiments you run and whether someone can own the warehouse side. The export delivers files to storage you control, so the first task is confirming which delivery options your contract and region support. Configuration capture is manual work in the Optimizely console or through its APIs, and flags that exist in only one environment are easy to miss. A consultant is useful when you want the export, reconciliation and replacement platform delivered as a fixed-scope project with written deliverables. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, and every engagement starts from a written scope.
What drives the effort of an Optimizely data export?
The main drivers are the number of flags and experiments, how many projects and environments they span, and how many metrics each experiment depends on. Event volume affects storage and the queries you run to check results. Reconciliation is often the largest hidden item: if stakeholders need the same numbers before and after cutover, you need a method to compare exported data with results in the new tool. Targeting rules, audiences and custom attributes take longer to review because they map less cleanly one-to-one. Ask whether your experiments use server SDKs, the web snippet or both, since each path leaves different artifacts. An inventory with named owners lets the team decide what to archive, what to recreate and what to retire.
How long does the export take, and what sets the timeline?
The timeline is set mainly by the inventory, the access approvals for admin and export settings, and the decisions about how much history you must keep. Access requests and security review of storage locations often take longer than the technical work. Reconciliation adds time because each discrepancy needs a cause and a decision. Your contract end date also matters, because you need the data and configuration before access ends. Ask any vendor for a timeline with named phases, the dependencies on your team and the checkpoints where you confirm results. Treat any duration quoted before the inventory and access are confirmed as provisional.
What does the export work need from our team?
Plan for four groups. Data engineering builds the landing zone, schedules the loads of daily event files and writes the queries that read them. A product owner decides which experiments, metrics and history must be kept, signs off on reconciliation tolerances and confirms which teams depend on each flag. Optimizely administrators grant read access to projects, environments and experiments, and someone must be able to explain why a configuration exists. Security and compliance staff review storage location, encryption, access logs and retention. Application engineering owners should confirm which flags are still referenced in code before anything is archived or removed.
What is one-time and what recurs after the export?
One-time costs include the inventory, export setup, configuration capture, reconciliation and any SDK or snippet changes if you move to a new platform. Recurring costs include cloud storage for the event files, the retention copies you keep, the warehouse queries that read them and the time someone spends answering questions about past experiments. Storage and query costs depend on event volume and retention length, so request pricing and usage figures from your cloud provider and warehouse vendor before you commit. After cutover, hosting, databases, backups and upgrades for the new platform become recurring operational work for your team, or work covered by a support retainer.
What should we ask for in a written consultant quote?
Ask for a written scope that lists each deliverable: the inventory of flags, experiments, audiences, metrics and environments; the export method and storage location; the reconciliation approach and acceptance criteria; the configuration captured and where it is stored; and the documentation and handover. Ask which items are excluded, what assumptions the quote makes about access, environment count and your team's time, and how scope changes are priced and approved. Require a timeline with milestones and the conditions that would move them. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and its quote follows from that written scope.
Do we need the daily events export if we only want our flag configuration?
Keep the daily events export if you need to explain past decisions, audit experiment history or rebuild analysis later. Flag configuration shows what was set, but the event records show who was exposed, when, and which metrics moved. If experiments informed decisions that fall under regulatory or contractual review, treat both datasets as records and confirm retention with your compliance owner. If you only need current flag states for a cutover, configuration capture may be enough. Your own retention policy governs how long copies stay, and the retention window Optimizely documents for its export does not replace an archive you need to keep yourself.
How DeployOpen scopes and delivers an Optimizely data exit
DeployOpen plans and delivers the data exit from Optimizely as a fixed-scope engagement inside your own infrastructure. We agree in writing what is exported, where it lands and how it is checked before the contract ends, so the export is complete and documented rather than assembled under deadline pressure.
How we scope
- We inventory the Optimizely projects, flags, experiments and audiences that need to be captured before the contract ends.
- We confirm which Experimentation Events Export data your team needs and how long it must be retained.
- We agree the storage target in writing, including the GCS-only rule that applies to EU customers.
How we build
- We configure the daily Parquet export pipeline into your own storage so raw events land before the S3 delivery change.
- We export flag and experiment configuration into documented files that your engineers can read without Optimizely.
- We test that row counts, timestamps and experiment identifiers reconcile against the source before anything is switched off.
How we hand over
- You receive the export pipeline configuration, run logs and a runbook for re-running or extending the export.
- We document the data dictionary so analysts can map Optimizely fields to your warehouse tables.
- We provide an evidence pack of reconciliation results that your auditors or compliance team can review.
How we support
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
- Ongoing support, upgrades and monitoring of the export job are available as a retainer.
- Questions about contract dates, vendor terms and export entitlements should be confirmed with Optimizely directly, and we can help document the answers.
