Migrate from Optimizely to GrowthBook: what the move involves
Moving from Optimizely to GrowthBook is a rebuild, not an import, and GrowthBook has no built-in Optimizely importer. If your renewal is driven by monthly active user billing, a data residency requirement or a wish to stop depending on one vendor's flag model, plan for every flag, experiment and metric to be recreated deliberately. GrowthBook does offer importers for LaunchDarkly and Statsig, but those read from other vendors' APIs and do not read Optimizely configuration, so you cannot point a tool at your Optimizely account and expect a finished setup. Platform engineering usually leads the work, with product owners who know which experiments matter and analytics owners who know where the numbers live. Expect the effort to depend on how many flags and experiments are still active, how many of them depend on Optimizely's stats engine behavior, and how much of your event data already sits in a warehouse GrowthBook can query. The short answer on effort and risk is that the technical swap is the smaller part. Each active flag has to be recreated through GrowthBook's API or UI, each SDK or web snippet call has to be replaced in code, and each success metric has to be redefined as SQL against your warehouse. The main risk is a silent change in results: a metric defined slightly differently, a different attribution window or a bucketing change can make a finished experiment look like a new one. Before cutover, run both platforms side by side on a sample of traffic and compare exposure counts and metric values against the Optimizely events export. Ask your team to document the mapping for each experiment so the comparison has a reference point. Also confirm with GrowthBook which self-hosted features your plan needs, since approval workflows, holdouts and sticky bucketing are Enterprise features on the self-hosted pricing page, not part of the free Open Source plan. Scope the work in writing before it starts. A fixed-scope agreement with DeployOpen should list the flags and experiments in scope, the warehouse sources and metric definitions to rebuild, the SDK and snippet changes in each application, the parallel-run period and the acceptance criteria for cutover. Ask any implementation partner to state what is one-time (inventory, metric rebuild, SDK changes, validation) and what recurs (hosting, database operations, upgrades, warehouse query spend and support). Your own team's time for product review and sign-off is also a real cost, and it is easy to leave out of a quote.
Which Optimizely capabilities map to GrowthBook, and which need rework
This table compares the main Optimizely capabilities with their GrowthBook counterparts and marks each as clean, needs rework or gap. Use it to scope the migration, then confirm every mapping against your own Optimizely configuration before you commit to a cutover date. The main takeaway is that flags and core experiments move with some effort, while the visual editor, some stats features and the events export need separate planning.
| Capability | GrowthBook position | Status and what to check |
|---|---|---|
| Feature flags and SDKs | GrowthBook has its own SDKs and flag evaluation. Application code must switch from the Optimizely SDK to a GrowthBook SDK after flags are recreated. | Needs rework. Plan code changes in every service that calls Optimizely, and confirm SDK language coverage for your stack. |
| Flag targeting rules, rollouts and fallback values | Targeting rules, percentage rollouts and default values are modeled as flag rules. Confirm each rule type against your Optimizely setup. | Clean for common rules. Needs rework for custom or nested logic. Verify rules one by one during recreation. |
| Experiments and variations | Experiments are defined in GrowthBook with variations, assignment and exposure tracking. Confirm how assignment and sticky bucketing behave for your traffic. | Needs rework. Sticky bucketing and holdouts are on the self-hosted Enterprise plan, per the GrowthBook pricing page. |
| Stats engine and results | GrowthBook provides its own statistics engine. Results will not match Optimizely figures one for one, so compare methods before trusting either. | Gap for exact parity. Some advanced stats features, such as multi-armed bandits, sit on the self-hosted Enterprise plan. Confirm which methods your team relies on. |
| Audiences and targeting attributes | Attributes and segments are defined in GrowthBook and passed by the SDK or evaluated against your data source. Confirm where each audience is computed. | Needs rework. Rebuild audiences and confirm attribute names match what your application sends. |
| Metrics | Metrics are rebuilt as SQL definitions on your warehouse or data source. Optimizely metrics do not transfer automatically. | Needs rework. Metric logic, conversion windows and event names must be recreated and validated against Optimizely results. |
| Web Experimentation visual editor and snippet | GrowthBook offers a visual editor and script tag, but it is tied to paid tiers. Confirm plan coverage and limits on client-side-rendered apps. | Gap on the free self-hosted plan. Visual editor access depends on the plan shown on the GrowthBook pricing page. Confirm with GrowthBook before planning. |
| Experimentation events export | GrowthBook reads event data from your warehouse with read-only SELECT queries and does not ingest the Optimizely export directly. | Needs rework. Load exported Parquet data into your warehouse and use it to check GrowthBook results before cutover. Confirm the export format and retention in your Optimizely account. |
What data and integrations you move, and what you rebuild
Optimizely does not feed GrowthBook automatically, so the move splits into three groups: configuration you export or capture, historical results you keep as a reference, and connections you rebuild in your own environment. Each card names one item in that inventory and what to check before cutover.
Flag and experiment configuration
Pull every flag, rule, audience, variation and traffic allocation through the Optimizely API, then store the output in version control before anything changes. GrowthBook has no Optimizely importer, so each item is recreated through GrowthBook's API or interface. Keep one inventory sheet that maps each Optimizely experiment to its GrowthBook feature or experiment ID, with status and owner. Confirm which endpoints your Optimizely contract exposes, because API access depends on the plan.
Experimentation Events Export
The Experimentation Events Export is a daily Parquet feed of raw exposure and conversion events. Treat it as the historical yardstick for cutover. GrowthBook does not import it. Load a sample window into your warehouse, recompute the same metrics in GrowthBook, and compare counts and conversion rates. Confirm the delivery destination and retention period in your Optimizely agreement, including the storage rules that apply to EU customers.
Warehouse connection and access
GrowthBook reads your exposure and metric tables through a data source connection that runs only read-only SELECT queries and returns aggregated statistics. Supported engines include BigQuery, Snowflake, Redshift, Databricks and Postgres. Create a dedicated service account with read access to the events schema only, and review its query logs during the parallel run. Ask your data team whether Optimizely events already land in that warehouse, since that determines where the connection points.
Identities, roles and SSO
Map every Optimizely user, role and project to a GrowthBook user and permission set before sending invitations. The free self-hosted Open Source plan includes unlimited users but only one project, so decide your project structure first. SSO, SCIM, advanced permissioning and approval workflows are listed on the self-hosted Enterprise tier, which the free plan does not include. Decide who approves production rollouts and confirm that the chosen tier provides each control your change process requires.
SDK and application code swap
Every service that calls the Optimizely SDK needs a GrowthBook SDK call or a provider change, and running both on the same flag key requires a deliberate plan. Inventory these calls by repository, then decide whether an OpenFeature layer would let you change the provider once instead of at each call site. Confirm which SDK languages and OpenFeature providers GrowthBook supports for your stack before you write that wrapper.
How metrics get rebuilt on your warehouse
The key decision in this part of the migration is that GrowthBook does not hold your Optimizely results. It analyzes each experiment against your own data source, so the metrics you rebuild must be defined on the same event data that Optimizely used. GrowthBook connects to warehouses such as BigQuery, Snowflake, Redshift and Databricks, along with Postgres, MySQL, Trino and others listed in the GrowthBook data source documentation. It runs only SELECT queries and transmits only aggregated statistics, so the raw events stay where they are. Confirm with your data team which warehouse holds your experiment events, which service account GrowthBook will use, and that the account is granted read access only to the tables it needs.
Redefine each Optimizely metric as a GrowthBook metric built on the same event definitions. Start from an inventory of every primary, secondary and guardrail metric attached to a running or recent experiment, then write down the event name, the value column, the filter conditions and the attribution window for each one. Map each item to a GrowthBook fact table and metric definition, and record where a definition cannot be expressed in the query builder. Optimizely's Experimentation Events Export uses its own event schema, so the mapping from its columns to your warehouse tables is the step most likely to change a result. Keep a written record of every mapping, because an auditor or stakeholder will ask how a metric was defined.
Verify the events data before any cutover decision. Run the same experiment window through both systems: count exposures per variation, compare conversion totals per metric and check that assignment is balanced. Differences usually come from deduplication rules, timezone boundaries, bot filtering or late-arriving events, not from the stats engine itself. Agree on an acceptable tolerance with the people who will sign off results, and do not switch decision-making to GrowthBook until a sample of experiments reconciles within it. Plan this comparison as a required milestone in the migration, not a final check.
The migration sequence from inventory to decommission
This sequence moves flags, experiments and metrics from Optimizely to self-hosted GrowthBook in controlled stages, so each step produces evidence that the next one depends on. Each stage ends with a written output that a named owner signs off before the old system is switched off.
Inventory flags, experiments, audiences and metrics
Export or list every Optimizely feature flag, rule, experiment, audience and metric, along with its environments, owners and the code paths that call it. Record each item in an inventory register with its status, traffic and dependencies, and mark the items that are still live or that feed reporting. The step is done when engineering and product owners have reviewed the register and every live item has an assigned owner and a target disposition: recreate, retire or leave in place.
Pilot one low-risk flag and one experiment
Choose one low-risk flag and one experiment that have a clear success metric and a short decision window. Recreate both in a self-hosted GrowthBook instance, deployed in your own cloud account or data center, and wire one non-critical service to the GrowthBook SDK. The output is a pilot readout that compares exposure counts and metric results from GrowthBook with what Optimizely reported for the same window, plus a list of gaps found during the pilot.
Recreate items through the GrowthBook API
Script the recreation of flags, environments, attributes, segments and experiments through GrowthBook's API rather than rebuilding them by hand in the interface. Keep the script and its input files under version control so the same definitions can be re-applied to staging and production. The check is a reconciliation table that maps each inventory entry to its GrowthBook identifier, with any item that could not be expressed in GrowthBook marked for a manual decision.
Swap SDKs and the web snippet
Replace the Optimizely Feature Experimentation SDK calls in application code with GrowthBook SDK calls, or put the GrowthBook SDK behind an OpenFeature provider if your code already uses that abstraction. For web experiments, confirm which tests run through the Optimizely snippet and plan how each one is removed or reproduced. The step is complete when a code search finds no remaining Optimizely calls in the services in scope and the test environment serves the expected variants.
Run a parallel comparison against the events export
Run both platforms side by side on the same traffic for each live experiment, and point GrowthBook's data source at your warehouse, where it runs read-only SELECT queries. Reconcile assignment counts and metric totals against the Optimizely experimentation events export, investigating every difference in attribution, bot filtering, timezone or metric definition. The output is a reconciliation report signed by the analytics owner that explains each variance before any decision is made on GrowthBook results.
Cut over with a signed checklist
Move production traffic to GrowthBook one flag or experiment group at a time, starting with the items already reconciled. Keep a rollback path to the previous Optimizely configuration until the cutover checklist is complete, and record the approver for each group. The step closes with a signed cutover checklist that lists every switched item, its verification evidence and its owner, and that the security and compliance leads have reviewed access controls on the new instance.
Decommission Optimizely and archive evidence
After the parallel run and cutover checks have passed and the reporting history you need has been exported and stored, remove the Optimizely SDKs, snippets and integrations from code and tag managers. Revoke API keys and service accounts, and confirm with Optimizely and your contract owner the exact date data access ends and what retention applies to exports. The output is a decommission record that lists removed components, revoked credentials and where archived experiment evidence is kept.
How the migration differs by starting point
If you use Optimizely Feature Experimentation alone, the work centers on application code. Flags, targeting rules and experiments are defined in Optimizely and read by server and client SDKs inside your services. GrowthBook has no Optimizely importer, so each flag and experiment is recreated, and the SDK calls in every service are replaced with a GrowthBook SDK. GrowthBook's importer documentation notes that the application still has to switch SDKs after an import, so plan for that switch as the largest engineering task.
- Inventory every evaluation call: Search each service, batch job and mobile build for Optimizely SDK initialization and every flag decision and tracking call.
- Recreate flags through the API: Script flag and experiment definitions into GrowthBook so targeting, rollout percentages and variation keys match what production evaluates today.
- Wrap flag calls behind one interface: A thin internal layer or an OpenFeature provider lets each service change its vendor calls in one place.
- Rebuild metrics on your warehouse: Each Optimizely metric becomes a GrowthBook metric defined against your own tables, which is often the slowest part of this path.
- Run shadow comparisons: Log assignments from both systems for the same users before cutover.
Confirm which languages and client SDKs your services use, then check them against GrowthBook's SDK list before you commit to a timeline.
If your team runs Optimizely Web Experimentation for marketing pages and conversion tests, the work centers on the snippet, the visual editor and the variants built in it. Application code is usually not involved, so the SDK replacement step is small. The harder questions are which tests are still live, how variants were written and whether the visual editor is available on the GrowthBook plan you will use. The GrowthBook pricing page ties the visual editor to paid tiers, and the free self-hosted Open Source plan does not list it, so confirm the current inclusion before you design the migration.
- Export the live test list: Record every running and scheduled test, its URL targeting, traffic split and primary goal.
- Decide the build path for each test: Rebuild simple copy and layout tests in GrowthBook's visual editor if your plan includes it, and write code-based variants for anything the editor cannot express cleanly.
- Replace the snippet in stages: Install the GrowthBook script on a staging site, then move one template or section at a time while watching for flicker and layout shift.
- Rebuild conversion metrics from analytics events: Map each goal to a warehouse query or an event your team already sends.
- Verify before retiring the snippet: Check that visitor bucketing and conversion counts agree on a sample of pages before you remove the Optimizely tag.
Ask your vendor or GrowthBook sales contact to confirm which plan includes the visual editor and whether your target pages render on the server or on the client.
Organizations that run both Optimizely Feature Experimentation and Web Experimentation face a coordination problem. The same visitor may be enrolled in a server-side test and a page-level test at once, so cutover has to keep assignments consistent while each product moves on its own schedule. A clear ownership map for every test prevents double bucketing, conflicting variants and duplicate metrics during the overlap period.
- Map ownership for every test: Record whether each test belongs to the code path or the Web snippet, and do not let two systems assign the same visitor to the same experiment.
- Keep users in the same group: GrowthBook's self-hosted Enterprise tier lists sticky bucketing among its features, which helps keep a user's assignment stable when the rollout changes.
- Sequence the cutover: Move low-risk Web tests first, then move server-side flags once the metric pipeline has matched results for several tests.
- Unify the metric layer: Define shared metrics such as revenue or sign-up once in the warehouse so both kinds of test report the same numbers.
- Plan the overlap window: Agree in writing on the date each Optimizely product stops receiving new tests and the date each one is switched off.
Before you start, confirm with GrowthBook which self-hosted features your use cases need, since several of them sit in the Enterprise tier rather than the free Open Source plan.
Organizations with several warehouses, regional data stores or strict EU data residency requirements face more design decisions. GrowthBook analyzes experiments in place: it runs read-only SELECT queries against your data source and transmits only aggregated statistics, according to its data source documentation. Metadata such as flags, experiments and users sits in a MongoDB or compatible database, and uploads go to local storage, Amazon S3 or Google Cloud Storage. Residency therefore depends on where each of these components runs, not only on the warehouse.
- List every metric source: Record each warehouse or database that holds experiment events, and confirm that GrowthBook supports its type, such as BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres or Trino.
- Check the region of each component: Confirm where the GrowthBook application, its MongoDB database and any S3 or Google Cloud Storage buckets run, and keep them in the required region.
- Set up a dedicated read-only role: Grant GrowthBook a database role limited to SELECT on the experiment tables it needs.
- Use the official Helm chart for Kubernetes: A standard deployment in the cluster you control makes the component map easier to document for auditors.
- Document the data flow: Write down which personal data reaches GrowthBook and which stays in the warehouse, and share the record with your privacy and compliance leads.
Confirm these details with your data protection officer and your hosting provider before the design is approved, since they determine what the assessment will ask.
What drives the cost and duration of the move
This table lists the inputs that change how much work the Optimizely to GrowthBook move takes and what it costs to run afterward. Read each row as a question to answer during inventory, then use the one-time and recurring columns to build a quote request that separates project work from ongoing operation.
| Driver | Why it changes cost or effort | One-time or recurring | How to keep it down |
|---|---|---|---|
| Number of flags and experiments | Each flag and experiment must be recreated or imported, with its targeting, rollout and variation logic checked by hand where the importer does not cover it | One-time | Retire stale flags before inventory and export only live configuration |
| Distinct SDK integrations across services | Every service that calls Optimizely's SDK needs a GrowthBook SDK swap and a retest, because the importer does not change application code | One-time | Group services by SDK and migrate them in batches with shared wrapper code |
| Metric count and warehouse complexity | Metrics are rebuilt as SQL against your own warehouse, so each metric needs a tested query, a data source and agreed definitions | One-time to build, recurring in query spend | Reuse shared metric definitions and limit experiments to metrics the business actually reads |
| Web Experimentation pages and client-side rendering | Snippet-based tests on many pages, or on single-page apps, need separate visual editor or script work and may not map cleanly to GrowthBook | One-time | Scope web tests to a short list of high-traffic pages and confirm rendering support early |
| Self-hosting components (MongoDB, Helm chart, file storage) | You run the Next.js front end, Express API and Python statistics engine, plus a MongoDB or compatible database and storage for uploads | Setup one-time, hosting and upgrades recurring | Use a managed MongoDB service and the official Helm chart, and standardize backups from day one |
| Upgrades such as the v5.1.0 release | GrowthBook v5.1.0 was released on September 22, 2026, so each new release needs testing against your SDKs, data sources and self-hosted stack | Recurring | Schedule a fixed upgrade cadence and test on a staging instance first |
| Parallel-run period | Running Optimizely and GrowthBook side by side keeps two sets of contracts, SDK calls and reporting active while results are compared | One-time, but duration depends on test volume | Agree the comparison criteria and cutover date in writing before the run starts |
| People involved | Engineering, data, product and security staff each carry part of the work, and a platform owner must run GrowthBook after cutover | Mostly one-time, plus recurring operations ownership | Name owners for flags, metrics and hosting before work begins |
Questions buyers ask before moving off Optimizely
Does GrowthBook have a built-in importer for Optimizely?
No supplied documentation describes a built-in Optimizely importer for GrowthBook, so plan the move as a scripted or manual rebuild. GrowthBook's documented importers cover LaunchDarkly and Statsig, which gives a useful pattern: the importer reads projects, environments and flags through an API with an access token. For Optimizely, you would export your flag and experiment configuration first (see the Optimizely data export guide in this group), then recreate each item through GrowthBook's API. Confirm the current import options with GrowthBook before you assume any tool exists.
How long does an Optimizely to GrowthBook move take?
No duration is supplied for this migration, so the honest answer depends on the work involved. The main drivers are the number of active flags and experiments, how many of them use targeting rules, prerequisites or holdouts, how many metrics must be rebuilt on your warehouse, and how many SDK integrations or web snippets need changing. Running results in parallel for a comparison period adds time, but it is the step that protects you at cutover. Ask any implementation partner for a fixed-scope plan built from a written inventory of your flags, experiments and metrics.
What does our internal team need to provide for the migration?
Your team needs to supply knowledge that exists only inside your organization. That includes the owners of each flag and experiment, the business definitions behind each metric, access to the warehouse tables that hold your event data, and someone who can approve SDK changes in each application. Engineering must also decide how the GrowthBook deployment will be hosted and how its MongoDB database will be backed up. Assign these owners before the inventory starts, because gaps in ownership are the most common reason a rebuild stalls.
Can we move from Optimizely to GrowthBook in-house?
Yes, an experienced platform or data team can do it in-house, provided it has capacity for the inventory, the SDK changes and the metric work. The steps are well defined: inventory, recreate, swap SDKs or the snippet, rebuild metrics on the warehouse, then compare results. What tends to be underestimated is the statistics and warehouse work, because GrowthBook runs its analysis against your own data source with read-only SELECT queries, so each metric needs a correct SQL definition. If that expertise is thin internally, a fixed-scope engagement can cover parts of the work while your team keeps ownership.
What does the free self-hosted GrowthBook plan include, and when do we need Enterprise?
The self-hosted Open Source plan is free with unlimited users, 1 project and unlimited API requests, according to GrowthBook's pricing page. If you need more than one project, the free plan will not cover the migration as planned, so count projects before you commit. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Teams with strict access control or formal change approval usually need these features. Check the current GrowthBook pricing page and get Enterprise terms in writing before cutover.
How do we check GrowthBook results against Optimizely before cutover?
Run both platforms in parallel on the same traffic for a defined period, then compare exposure counts, assignment rates and metric values for each experiment. Use the Optimizely experimentation events export as the reference, and recompute the same metrics from your warehouse in GrowthBook. Differences usually come from metric definitions, attribution windows, bot filtering or assignment logic rather than the statistics engine, so document each one. Agree on acceptable tolerances with the metric owners before the comparison starts. Only cut over when each active experiment reconciles or its differences are understood.
What happens to our SDK code during the switch?
Your application code has to change from the Optimizely SDK or snippet to a GrowthBook SDK, because importing flag definitions does not change the code that evaluates them. GrowthBook's LaunchDarkly guidance makes the same point: the application still has to switch SDKs after the import. Keep changes small by wrapping flag calls in one internal interface, so that each call site changes once. Test fallback values, user attributes and bucketing in staging, since a different hashing or assignment behavior can move users between variations during cutover.
What usually goes wrong and how to prevent it
Most failed Optimizely to GrowthBook moves do not fail in the tooling. They fail in the gaps between two systems that each hold part of the truth about a flag or a metric. The cards below cover the failure points we see most often and a prevention step for each. The GrowthBook LaunchDarkly importer documentation warns that advanced setups can include scenarios the importer cannot handle, so expect similar gaps when moving from Optimizely.
Parallel run results do not match
Optimizely and GrowthBook assign users to variants with different hashing, and they count exposures and conversions on different timestamps and identifiers. A gap in assignment or exposure counts can make a winning variant look different in each tool, which is the first thing stakeholders will question. Before cutover, compare assignment ratios and exposure counts for the same period in both systems, and agree on a tolerance in writing. Investigate any gap that goes beyond it before you trust either result.
Metric definitions drift from Optimizely
An Optimizely metric and a GrowthBook metric with the same name often differ in attribution window, deduplication, filters or the event used as the conversion. GrowthBook computes metrics with SQL against your warehouse, so each definition must be written again and reviewed by the people who own the business numbers. Export the Optimizely metric definitions, write each GrowthBook metric next to its source, and record any change in a shared decision log so the new result can be explained.
SDK swap missed in one service
A flag can be evaluated by the Optimizely SDK in one service and by the GrowthBook SDK in another, so users can see different variants depending on which path they hit. This is common in microservices, mobile apps and batch jobs that were not on the original inventory. Build an inventory of every repository and runtime that calls Optimizely, and use a search of dependency files and code for the Optimizely SDK package names before you schedule each cutover.
Flags left live in both systems
When a flag is recreated in GrowthBook but still active in Optimizely, two systems can each serve a variant, and nobody knows which one is authoritative. Teams often forget the second system once the first one looks correct. Set a single owner per experiment, a cutover date, and a rule that Optimizely is switched off for that key only after GrowthBook serves traffic for it. Keep a checklist with a sign-off for each flag key.
Undocumented targeting logic
Audience conditions, custom attributes and rules added by developers over several years often exist only in the Optimizely interface or in application code that reads its decisions. The GrowthBook importer may not carry every rule across, so an audience can silently change scope. For each live flag, write down the targeting in plain language, compare it with the GrowthBook rule, and test with sample user attributes that cover the edge cases you know about.
Self-hosted operations gaps
Running GrowthBook yourself means you own the Docker image, the Node.js and Python services and a MongoDB or compatible database that stores experiment metadata. Gaps appear when no one has tested a restore of that database, or when backups do not cover the uploads storage. Before cutover, confirm who patches the image and the database, set up tested backups for MongoDB with a documented restore procedure, and run monitoring on the API and the statistics engine. Ask your vendor or your team to confirm the backup and upgrade steps for your chosen deployment method.
Who needs to be involved on your side
Product owners for experiments are the first people to name, because they decide which Optimizely flags and experiments are still live, which are stale, and which must keep their current traffic split through cutover. Ask each owner to sign off on a list of active experiments, their primary metrics, and the audience each one targets. Without that sign-off, the import will carry over configuration but nobody will be able to say whether a result still means what it meant in Optimizely. The data team owns the part that has no built-in importer. GrowthBook runs read-only SELECT queries against your own warehouse, so someone on the data side must recreate each metric definition, confirm the exposure and event tables, and agree which identifiers link assignment to outcomes. The same team should run the comparison against the Optimizely Experimentation Events Export before cutover, since that comparison is the main evidence that the rebuilt metrics match the old numbers. Confirm which warehouse your data sits in and whether the team has read access for the GrowthBook service account.
Engineering handles the code changes that no importer can make. The GrowthBook documentation for its LaunchDarkly importer notes that the application still has to move from the vendor SDK to a GrowthBook SDK after the import, and the same applies to an Optimizely codebase. Engineering should map every Optimizely call site, decide the SDK for each language, and schedule the switch behind a deploy so flag reads never run against two systems at once. Security owns the access tokens for the Optimizely API and any GrowthBook API keys, the hosting decisions for the GrowthBook service and its MongoDB database, and sign-off on where the aggregated statistics are stored. Confirm with your security team which secrets store will hold each credential before the first import run. DeployOpen's part is the implementation work: inventory support, recreating flags and experiments through the GrowthBook API, the metric rebuild on your warehouse, the result comparison, and the cutover runbook. Most engagements of this kind are fixed-scope, so the roles above, the deliverables and the timeline are written down before work starts, and the quote follows from that written scope. Ask each party to name one accountable person in the statement of work so that open decisions have an owner.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Optimizely to GrowthBook move, we start from a written scope that covers flags, experiments, metrics and cutover, then build and check the result against your existing Optimizely data before anything goes live.
How we scope
- Inventory of Optimizely feature flags, experiments, audiences and events agreed in writing before work starts
- Decision on which GrowthBook edition fits, given the free self-hosted plan limits and Enterprise features you need
- Agreed list of metrics to rebuild on your warehouse, with the data sources and access each one requires
How we build
- Self-hosted GrowthBook deployed in your environment, with MongoDB, file storage and the Helm chart set up for your platform
- Flags and experiments recreated through the GrowthBook API, with SDK or web snippet swaps planned per application
- Warehouse SELECT queries and metric definitions tested against the Optimizely events export before cutover
How we hand over
- Documented runbook covering configuration, deployment, backups and the flag and experiment inventory as built
- Written record of how each Optimizely result was reconciled with its GrowthBook counterpart before cutover
- Handover session with your engineering, data and compliance owners on what was moved, what was not, and why
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Upgrade planning for each GrowthBook release, so self-hosted versions stay current with your change process
- Clear scope boundary: items the migration did not cover are listed and quoted separately under a new written scope
