Migrate from Amplitude to PostHog: what moves, what needs rework
Event history can move from Amplitude to PostHog, but dashboards, cohorts, SDK instrumentation and identity logic need deliberate rebuilding. A team usually starts this work when an Amplitude renewal, a plan or event pricing change, or a data residency requirement forces a decision. PostHog's managed migration connects to Amplitude with API credentials, converts Amplitude events into PostHog's schema and remaps event names and properties, but it also drops some events. Each direct import job covers at most one year of data, so a multi-year history is moved as a series of jobs, each one checked before the next starts. Confirm in PostHog's managed migrations documentation which event types and properties are dropped before you map your taxonomy, because anything dropped must be rebuilt or accepted as lost.
The work is usually owned by the product analytics owner, who decides which dashboards and cohorts matter, with a data engineer or platform engineer running the imports and the SDK changes. Sometimes an implementation partner supports the cutover. The largest risks sit in two places. First, PostHog's managed migrations do not deduplicate events, so importing an overlapping date range or running a job twice creates double counts that cannot be selectively deleted later. Second, identity mapping: the migration can generate identify and group identify events, which is the only way to bring groups over from Amplitude, but the user IDs and device IDs used by your SDKs must line up with the historical records. Agree on a single import plan with non-overlapping date windows and a documented identity mapping before the first job runs.
The hosting decision belongs in the plan from the start. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not provide customer support for product or infrastructure questions on them. The free hobby Docker Compose deployment is useful for evaluation, but a regulated team that needs accountable support, upgrades and backups should decide between PostHog Cloud (US or EU region) and a self-hosted deployment with an internal or contracted operator. Ask PostHog to confirm which features and import paths are available in each option, and ask your own security and compliance team which residency and access rules apply before any production data is moved.
Which Amplitude capabilities map cleanly to PostHog
This table maps the main Amplitude capabilities to their closest PostHog equivalents and marks each row as clean, needs rework or gap. Use it to scope which dashboards, cohorts and experiments can move with the historical import and which need to be rebuilt by hand. Confirm feature parity against your exact Amplitude plan and the PostHog version you run before you commit to a cutover date.
| Amplitude capability | PostHog equivalent | Status | What to check |
|---|---|---|---|
| Event analytics and event taxonomy | Event tracking with properties and autocapture in product analytics | Needs rework | Event names are remapped during import, so confirm each renamed event and its properties in a test project before cutover. |
| Funnels | Product analytics funnels built on imported events | Clean | Rebuild each funnel and compare step counts over the same date window after the import job finishes. |
| Retention and cohorts | Retention insights and person cohorts | Clean | Cohorts depend on identify events, so confirm user IDs match between the two systems. |
| User properties | Person properties set through identify events | Clean | Generate identify events in the managed migration, then spot-check profiles for missing properties. |
| Group analytics | Group identify events and group-based insights | Clean | Clean only where identify and group events are generated during migration. Confirm group types and keys before relying on them. |
| Saved charts, dashboards and taxonomy tools | Dashboards and data management tools with different structure | Needs rework | Chart-level saved views and Amplitude taxonomy features do not carry over one to one. Plan to recreate them. |
| SDK tracking | PostHog SDKs for web, mobile and server | Needs rework | Replace Amplitude SDK calls in code and run both in parallel for a short overlap to check event counts. |
| Experiments and feature flags | PostHog feature flags and experiments | Gap | Amplitude experiment definitions do not migrate. Recreate flags and experiments and confirm they are supported on your plan. |
Which history, identities and integrations to move
A migration from Amplitude to PostHog moves more than raw events. Identities, group records, renamed events and downstream feeds all need an owner and a check before the first import job runs. The cards below cover the source options and the items that must be inventoried so nothing is lost silently during conversion.
Managed import with Amplitude credentials
PostHog's managed migration connects directly to Amplitude with API credentials and converts Amplitude events into PostHog's schema. Event names and properties are remapped during conversion, and some events are dropped. Create a read-only Amplitude credential for the migration, run one job per year of history, and compare event counts per year against Amplitude before you rely on the imported data.
Amplitude Export API as archive
Keep a raw copy of your Amplitude events in case a managed import drops or reshapes something you need. The Export API returns zipped JSON, and its request limits shape how you split the export by date range. Store the archive in your own object storage with a retention rule that your compliance team has approved, and confirm the current file size and rate limits in Amplitude's documentation before you schedule it.
JSONL files in S3 as input
PostHog's managed migrations can also read historical events from JSONL files in an S3 bucket. This route suits teams that already hold an Amplitude export and want PostHog to import from their own storage. Check that each file follows the schema PostHog expects, that timestamps and user identifiers survive the conversion, and that the bucket access policy limits reads to the migration job.
Identities and aliases
Users must keep the same identifier across both systems, or PostHog will count one person as several. Inventory how Amplitude user IDs and device IDs map to the identifiers your SDKs send today, including any anonymous-to-known merges. Decide which identity events the migration should generate, and test a sample of known users before importing the full history.
Groups and identify events
PostHog's managed migration can generate identify and group identify events from Amplitude, and PostHog states that this is the only way to import groups from Amplitude. List every group type you use for accounts, workspaces or organizations, and confirm that each one is present in the output. Groups that are missing after import usually break company-level dashboards and cohorts.
Event renames and dropped events
Create a table that maps each Amplitude event and property to its PostHog name, and mark the events that must survive conversion. Review the drop list with analytics owners before the first run, because a dropped event cannot be recovered from PostHog later, and PostHog provides no way to selectively delete imported event data. Also list downstream feeds such as warehouse exports, reverse ETL jobs and alerts, and rebuild each one against the new names.
Migration sequence from inventory to decommission
This sequence moves product analytics from Amplitude to PostHog in controlled stages, so each step produces evidence that the next one depends on. Teams finish with a verified event map, a reconciled history, a parallel run they have checked against Amplitude, and a documented decision to retire Amplitude.
Inventory events, properties, identities and dashboards
Export a list of every event name, property and user or group identifier your Amplitude project uses, then list the dashboards, cohorts and funnels that depend on them. Product owners and analytics engineers should work through this together, because some events exist only for dashboards nobody reads. The output is an event map: each Amplitude event mapped to a PostHog event name, the properties to keep, and the events you intend to drop. The step is done when every dashboard in use maps to events on this list.
Run a pilot import of one year for one project
Connect one PostHog project to a single Amplitude project using API credentials and import one year of history, which is the maximum each direct import job covers. Check that remapped event names and properties match the event map and that the events you chose to drop are absent. Compare event counts for a sample of days against Amplitude's own figures. The output is a pilot reconciliation report listing mismatches and their causes, which decides whether the mapping needs another pass before any full import.
Generate identify and group events during the import
Enable identify and group identify event generation in the managed migration so that user profiles and groups carry over, since PostHog states this is the only way to import groups from Amplitude. Verify a sample of users and groups in PostHog against Amplitude, paying attention to traits that changed over time. The output is a profile and group check signed off by the analytics owner.
Import remaining history in separate jobs without duplicates
Run the remaining history as separate direct import jobs, each covering a date range within the one-year limit. Managed migrations do not deduplicate events, so the job plan must not overlap date ranges and each range should run once. Keep a log of job IDs, date ranges and event counts. The output is an import ledger that shows complete, non-overlapping coverage, and the reconciliation report is updated to cover the full history.
Instrument PostHog SDKs alongside Amplitude
Add the PostHog SDK to the same web and mobile releases that still send events to Amplitude, using the event map so new events match the historical schema. Both tools receive events during this period, which lets you compare live data. Engineers confirm in a test environment that identify calls and group calls fire with the same identifiers used in the import. The output is a release checklist showing which surfaces send to which tool.
Compare key funnels in a controlled parallel run
For a fixed set of funnels, retention views and cohorts that the business relies on, compute results in both tools over the same period and record the differences. Investigate gaps caused by SDK timing, bot filtering, or events you dropped on purpose, and document each one. The output is a parallel run report that states which differences are accepted and why, and it is approved by the owners of the affected dashboards before cutover.
Cut over SDK writes to PostHog
Remove Amplitude SDK calls from client and server code in a scheduled release, and confirm that only PostHog receives production events. Update dashboards, alerts and any downstream exports to read from PostHog. The output is a signed cutover checklist with the release identifier, the owner for each surface, the rollback plan and the date each dashboard was switched.
Decommission Amplitude after retention needs are met
Before you stop using Amplitude, export the data your records, audit or legal retention rules require, because there is no way to selectively delete event data once imported into PostHog and export is how you keep the history you still need elsewhere. Confirm with your compliance team which datasets must be kept, then close the Amplitude project and remove its API keys from configuration. The output is a decommission record that lists the retained exports, their storage location and the approver for closing the account.
How managed import handles identity, groups and duplicates
The managed migration connects to Amplitude with API credentials, reads the historical events, and converts them into PostHog's schema. During that conversion it remaps event names and properties, and it drops some events, so the reader should not assume that every Amplitude event arrives unchanged. Before the first job, export a sample of Amplitude events, list the names and properties you rely on, and confirm in the migration preview or the PostHog docs which of them are renamed or skipped. Identity is handled through the same conversion. The managed migration can also generate identify and group identify events, which PostHog describes as the only way to import groups from Amplitude. If your analysis depends on account or organization breakdowns, enable group generation on the test job and check that group keys match the ones your PostHog groups will use.
Each direct import job covers at most one year of history, so a multi-year migration is a sequence of jobs. Managed migrations do not deduplicate events. If two jobs overlap in date range, the same Amplitude event is stored twice and every count inflated by that overlap is wrong. Plan non-overlapping date windows on paper before starting, record each window and its job status, and do not rerun a window without first confirming that the earlier run is complete. Live traffic adds a second source of duplication: if the new PostHog SDK sends events for the same period while the import is running, or if you keep Amplitude SDKs and PostHog SDKs both active during cutover, the same user action can appear twice. Choose a cutover boundary, stop sending to the old pipeline for the imported window, and confirm that the boundary is respected in both systems.
Imported event data cannot be selectively deleted once it is in PostHog. You cannot remove one bad job or one mislabeled property from the project after the fact, so the safe path is a separate test project, a small first job, and a review of the resulting events, identities and group counts against Amplitude's own figures before you run the full plan. Ask your PostHog representative or review the managed migration documentation to confirm the current import limits and the paid product analytics plan that the import features require. Keep the test project's findings, the date windows used and the cutover timestamp in your migration record so that anyone reviewing the analytics later can explain every imported event.
What drives migration cost and duration
This table lists the factors that change the effort and recurring spend of moving from Amplitude to PostHog, and how each one can be reduced. Read each row as a question to answer before requesting a scoped quote, since most drivers compound when they appear together.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Total event volume and years of history | Each direct import job covers at most one year of data, so multiple years mean multiple jobs, each needing configuration, checking and sign-off. | Confirm which years are needed for trend analysis and import only that window. Ask the vendor how many jobs your export volume implies. |
| Event types and properties to remap | Managed migrations convert Amplitude events into PostHog's schema and remap event names and properties, and some events are dropped. Every mapping needs review against existing dashboards. | Inventory event names and properties before starting. Retire unused events in Amplitude first so fewer mappings are needed. |
| Number of SDKs and platforms to re-instrument | Historical import does not replace live tracking. Each web, mobile and server SDK must be switched so new events arrive in PostHog, and each platform needs its own release cycle. | List every SDK version in production and plan releases per platform. Run both tools in parallel for a defined period to confirm parity. |
| Dashboards, cohorts and saved analyses | Charts and cohorts must be rebuilt or rewritten in PostHog, and their definitions depend on the remapped event names from the migration. | Rank assets by business use and rebuild only those still in active use. Archive the rest rather than migrating everything. |
| Identity merge rules and group identify events | Users must be linked correctly across anonymous and identified sessions. The managed migration can generate identify and group identify events, which is the only way to import groups from Amplitude, so the merge logic must be settled first. | Document how Amplitude IDs map to PostHog distinct IDs. Test identify and group output on a sample before running full jobs. |
| Duplicate imports | Managed migrations do not deduplicate events, so re-running a job or overlapping date ranges can double count history. There is no way to selectively delete imported event data. | Keep a job log with date ranges and status. Test on a non-production project where possible and agree the import plan in writing before any run. |
| Paid product analytics plan | Historical imports are free of ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. This is a recurring cost for as long as the import features are needed. | Confirm which plan unlocks import features and for how long you need it. Ask whether the import window can be scheduled so the paid period is short. |
| PostHog deployment: Cloud EU, Cloud US or self-hosted | Cloud EU and Cloud US are hosted by PostHog, with the EU region in Frankfurt and the US region in Virginia. A self-hosted hobby deployment carries server sizing, operations and in-house upkeep, and PostHog states it is officially unsupported with no customer support for self-hosted instances. | Choose the hosting region that matches your residency rules before the first import. For self-hosting, price server operations and support in the quote, and confirm which features need the licensed ee directory. |
What usually goes wrong and how to prevent it
Most Amplitude to PostHog migrations fail in predictable places: data is duplicated, groups go missing, events are dropped silently, or an import lands in the wrong project. Each card below names one failure, why it matters for this migration, and the check that catches it before it reaches production dashboards.
Duplicate events from overlapping windows
PostHog's managed migrations do not deduplicate events, and each direct import job covers at most one year. If two jobs overlap, or if live tracking keeps running while history is imported, the same user action can appear twice and inflate funnels and retention. Set non-overlapping date ranges in writing, and keep a single import owner who records each job's window. Run a count comparison for a sample week in Amplitude and the test project before you trust the totals. Confirm with PostHog how the live SDK and the historical_migration flag interact in your setup.
Lost groups without identify events
Group analysis in PostHog depends on group identify events. PostHog says that generating identify and group identify events in the managed migration is the only way to import groups from Amplitude. If that option is left off, accounts, workspaces or organizations will exist as user-level data only, and any B2B dashboard built on groups will show empty or wrong results. Before the production run, list every group type you use in Amplitude, then verify in the test project that each one appears with its properties.
Silent drops during event remapping
The migration renames event names and properties to PostHog's schema and drops some events in the process. Nothing fails loudly, so a dashboard can look normal while a metric quietly loses a source. Build a mapping table that lists each Amplitude event, its PostHog name, and whether it is kept or dropped. Then reconcile daily counts for your ten most important events between the two systems and treat any unexplained gap as a blocker.
Irreversible imports into the wrong project
There is no way to selectively delete event data once it has been imported into PostHog. An import pointed at a production project, or with the wrong credentials or date range, cannot be partly undone. Run the first job into a dedicated test project, check counts and properties, and only then repeat the same settings against production. Write a rollback plan that covers the production SDK keys and dashboards, and confirm who may approve each import job.
SDK version gaps across web and mobile
Web, iOS and Android apps update on different schedules, so some users will still send Amplitude SDK events after you switch. Mixed instrumentation can split one user into two identities or change event names mid-release. Inventory the SDK version in each platform, plan a date after which the old SDK is retired, and check identity handling on a test device. Ask PostHog's documentation team which SDK versions your platforms require before you start.
Self-hosted operations without an owner
PostHog states that self-hosted deployments are officially unsupported and that it does not offer customer support for product or infrastructure questions on them. If the hobby Docker Compose deployment is chosen, failed upgrades, storage growth and ingestion faults become your team's problem with no vendor escalation path. Name an internal owner for the stack, a backup and restore test, and an upgrade schedule before the import begins. Compare this with PostHog Cloud, where hosting and support are part of the paid service.
How the migration differs by starting point
A small team on one Amplitude project with modest history usually has the simplest path. There are few event names, few SDKs and a short list of dashboards to rebuild, so the work is mostly in choosing the hosting option and checking that the import covers what the team needs. Because a direct import job covers at most one year of data, a short history may fit in a single job, and the team can judge whether older data is worth the effort at all.
- Hosting choice: Decide early between PostHog Cloud and a self-hosted deployment. The self-host documentation says self-hosted deployments are officially unsupported, so a team without in-house operations skills should weigh that before building on it.
- Single job: Confirm the date range of the Amplitude history and whether one import job of up to one year covers it.
- Event names: Review a short list of event names and properties before the managed migration remaps them.
- Dashboards: Rebuild the handful of key funnels and retention views in PostHog and compare the numbers with Amplitude for the same period.
- Plan: Confirm the paid product analytics plan that the import features require.
Before starting, confirm the hosting model, the history window and the plan terms in writing with the PostHog pricing page and your own environment.
A large product with many SDKs, several apps and years of data needs a longer, staged plan. History has to be split into several direct import jobs, each capped at one year, and the team must avoid importing the same window twice because managed migrations do not deduplicate events. The number of SDK versions in production also determines how long old and new tracking code will run side by side.
- Job plan: Map each year of history to a separate import job and record which windows are done.
- Duplicates: Because events are not deduplicated, never re-run a window that has already been imported, and keep a log of job dates and ranges.
- Identify and groups: Decide whether to generate identify and group identify events, since PostHog says this is the only way to import groups from Amplitude.
- SDK inventory: List every SDK version in each app and plan the switch in waves, so live traffic is not split without a reason.
- Volume: Estimate event volumes with your finance and engineering leads before deciding between Cloud and self-hosting, since the README advises moving to PostHog Cloud above roughly 100k events per month for open-source deployments.
Ask PostHog to confirm how the import handles your largest windows before scheduling any job.
A regulated team needing EU hosting and data residency decisions should settle where data lives before any import starts. PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions, and self-hosting moves the operational duties onto the organization. Historical events carry personal data and identifiers from years past, so the legal basis, retention periods and transfer assessments need sign-off before the first job runs, since deleted event data cannot be selectively removed once imported.
- Region: Choose the PostHog Cloud region or the self-hosted location and document the reason in the processing record.
- Deletion limits: Note that there is no way to selectively delete imported event data, so limit what is imported to what the purpose requires.
- Transfers: If a US provider is involved, review the position under the EU-US Data Privacy Framework with your legal team, since the Commission's adequacy decision of July 10, 2023 covers only participating companies.
- Retention: Compare the retention terms of each plan against your internal schedule.
- Support: Confirm in writing what support covers, since self-hosted instances receive no customer support from PostHog.
Have the data protection officer and security team approve the region and import scope before the migration plan is scheduled.
A team that also uses Amplitude Experiment or session tools has more moving parts. Experiments, feature flags and recordings often depend on the same event names and user identifiers as the analytics data, so a rename during the import can break a running test or a saved funnel. The sequencing should keep active experiments stable while analytics history is moved and the new tools are switched on.
- Experiments: Decide whether experiments move to PostHog, which bundles feature flags and experiments, or to a separate tool such as GrowthBook, and plan that choice as its own track.
- Event names: Check which event names drive running experiments and avoid remapping them until those tests end.
- Session data: Confirm which session replay or recording data stays in the current tool and which will be collected in PostHog from the switch date forward.
- Parallel running: Keep both tools receiving events for a period so results can be compared, and confirm the duration with your own analysts.
- Identifiers: Verify that user IDs match across tools so cohorts line up after the switch.
List every experiment and recording dependency before setting the cutover date.
Questions teams ask before migrating from Amplitude to PostHog
How much effort does an Amplitude to PostHog migration take?
The effort depends mostly on how much history you need, how many event names need remapping, and how many identify and group events you must generate. PostHog's managed migration connects to Amplitude with API credentials and converts events into its schema, but each direct import job covers at most one year of data, so a multi-year history means several jobs. Event name mapping, property checks and parallel validation are the work that scales with the size of your tracking plan. Ask any implementation partner for a written scope that lists the jobs, mappings and validation steps before agreeing a timeline.
Can our internal team run the migration without outside help?
A team with someone who knows the Amplitude event taxonomy and has rights to create PostHog projects can run the managed migration itself. PostHog's managed migration is a configured import, not a custom build. The harder parts are deciding which events to remap, avoiding duplicate imports, and checking that dashboards match before cutover. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances, so the internal team owns that support load. If that gap is a concern, ask whether a fixed-scope engagement covering setup, hardening, backups and runbooks fits your requirements.
What does the migration need from engineering, analytics and security?
Each group has a distinct job. Engineering replaces Amplitude SDK calls with PostHog SDKs, decides where PostHog is hosted, and manages the server, backups and upgrades if you self-host. Analytics owns the event map, confirms which events are dropped during conversion, and checks that funnels, retention and cohorts reproduce on known periods. Security reviews where the data sits, who holds Amplitude API credentials during the import, and how credentials are removed afterward. PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions, so residency should be decided before any historical data moves. Your auditors can assess the controls, but DeployOpen prepares the systems and evidence rather than issuing any attestation.
Can we import our full Amplitude history in one go?
Not in one job. PostHog's direct import supports a maximum date range of one year per job, so a longer history requires one job per year, each run and checked separately. Managed migrations also do not deduplicate events, so rerunning an overlapping date range will create duplicate records. Plan a job calendar with non-overlapping date windows and keep a record of each completed window. Note that there is no way to selectively delete event data once imported, so confirm the ranges and mappings on a small window before running the full history.
Can we switch off Amplitude as soon as the import finishes?
No. Run both tools in parallel until the important dashboards, cohorts and experiments match on comparable date ranges and your SDK changes are live across every client. Some events are dropped during conversion, and identify and group events are generated rather than copied, so differences are expected and must be documented. Keep Amplitude readable for the overlap period and export any data you need to keep before your contract ends, since the export options and limits are covered in a separate guide. Set the cutover date only after the parallel comparison is signed off by analytics and the business owners of each dashboard.
Is the self-hosted PostHog option supported for production use?
PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. The free Docker Compose hobby deployment is MIT licensed and installed with a deploy-hobby script, and PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that. It also notes that new Kubernetes deployments of the paid self-hosted product are no longer supported. Confirm current supported options with PostHog before choosing a hosting model.
What does requiring a paid PostHog plan mean for our cost?
Historical imports are free of ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. That means the migration itself carries a recurring subscription cost on top of any event charges for live traffic. PostHog's pricing page says the first 1 million analytics events are free every month, the Free plan includes 1 project and 1-year data retention, and the Pay-as-you-go plan raises this to 6 projects and 7-year data retention. Ask for the plan that covers your import, your retention needs and your projected monthly events, and compare it with your current Amplitude invoice and the cost of running your own servers if you self-host.
Can PostHog recreate our identify and group data from Amplitude?
Yes, with a caveat. The managed migration can generate identify and group identify events from Amplitude, and PostHog says this is the only way to import groups from Amplitude. That matters for B2B reporting where accounts drive the analysis. Check that user identifiers match across both systems before the import, because identify events link past activity to people, and a mismatch will split one customer into several profiles. Validate a sample of group-level funnels against Amplitude before you rely on them for decisions.
How DeployOpen scopes and runs an Amplitude to PostHog migration
DeployOpen plans, implements, integrates, documents and hands over self-hosted open-source platforms inside your own infrastructure, and this page's migration follows the same approach. Engagements are fixed-scope, so the scope, deliverables and timelines for moving from Amplitude to PostHog are agreed in writing before any work starts.
How we scope
- Inventory the Amplitude projects, event taxonomy, identify and group usage that the migration must carry over.
- Confirm which PostHog deployment fits the data residency requirement, including Cloud region or self-hosted option.
- Record in the written scope which Amplitude history ranges, event remaps and SDK changes are included and excluded.
How we build
- Set up the Amplitude API credentials and run one-year import jobs in a controlled order against a test PostHog project.
- Build the event name and property remapping rules, and generate identify and group events from Amplitude data.
- Plan import job sequencing to avoid duplicate events, since managed migrations do not deduplicate, and test results before the production run.
How we hand over
- Document the import runs, mapping tables, dropped events and reconciliation checks so your team can audit the result.
- Provide the SDK switch plan, including a parallel-running period and a cutover checklist for each application.
- Deliver runbooks for operating the chosen PostHog instance, with the paid product analytics plan requirement recorded.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any vendor or license question about the ee directory or Cloud plan in writing before the scope is signed.
- Confirm with PostHog, in writing, which support terms apply to your chosen deployment, since self-hosted instances carry no vendor support.
