How to migrate from Amazon OpenSearch Service without losing the configuration around your data
The data move is the smaller part of leaving Amazon OpenSearch Service. The security, index lifecycle, ingestion and dashboard configuration must be rebuilt and verified on the target cluster, because a copy of the indices does not carry them across. That configuration lives in the domain settings, access policies, pipeline definitions and Dashboards saved objects. Effort depends on three things: the volume of data you will move, the number of integrations that write to or read from the domain, and how much of the configuration sits outside the cluster in infrastructure-as-code, pipeline tooling or application code. Before you estimate, confirm the source domain version and the target OpenSearch version against the OpenSearch releases and maintenance pages, since both determine which migration path is supported.
OpenSearch is licensed under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe a paid edition. There is no license to buy or transfer, so the work is planning, build and operations: sizing target nodes, deciding who runs upgrades and patches, and setting up the security plugin, snapshots and monitoring that AWS operated for you. Ask your team to inventory what the managed service did in the background. Automated snapshots, patching, node replacement and some domain-level settings become your responsibility on infrastructure you control. Check each of these behaviors in your domain's configuration and the AWS documentation for your version, and record the answer next to the matching item in your plan.
Start with access, because it is the item most likely to be silently wrong after cutover. A managed domain typically combines AWS IAM policies, fine-grained access control and a sign-in method configured in AWS. On the target, the OpenSearch Security plugin provides role-based access control, document-level and field-level security, field masking, audit logs and TLS for node and client traffic. It supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token authentication backends. Map each source role, tenant and index permission to a target role, then test that sample users see the same documents and fields. Confirm that TLS certificates, node-to-node encryption and audit logging are active before any user or producer traffic reaches the new cluster.
Index lifecycle, ingestion and dashboards come next. Export every index state management policy and its attachment to indices, recreate them on the target, and confirm that rollover aliases, retention periods and deletion timing match the source. List every producer that writes to the domain, including Logstash, Data Prepper, the OpenTelemetry Collector, Firehose and custom clients, then repoint each one at the new endpoint with matching index templates and ingest pipelines. Export Dashboards saved objects, index patterns and tenants, and check key visualizations against query results you already trust. Keep a per-item checklist with an owner and a sign-off date, and keep the source domain read-only until every item passes.
Which managed service features map to self-hosted OpenSearch and which need rebuilding
This table maps each Amazon OpenSearch Service feature in scope to its self-hosted OpenSearch equivalent, with notes on what migration tooling moves and what your team recreates. Read the middle column for the target feature and the last column for the work it leaves you. The main takeaway is that index data and mappings are the most likely to move with the migration, while security, lifecycle, pipeline and dashboard configuration needs to be rebuilt and tested on your cluster.
| Managed service capability | Self-hosted OpenSearch equivalent | Migration notes |
|---|---|---|
| Index mappings, settings and documents | Index mappings and settings, moved with Migration Assistant | Migration Assistant can move indices across several major versions in one step. Review analyzers and mappings after the move. |
| Snapshots and restore | Snapshot and restore, one of four documented upgrade and migration methods | Confirm access to existing snapshot repositories. Plan a repository in storage you control for cutover fallback and backups. |
| Users, roles and fine-grained access control | OpenSearch Security role-based access, document-level and field-level security, field masking | Recreate users, roles and role mappings. Test each role with sample users before cutover. |
| TLS and authentication backends | TLS for node and client traffic; SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JWT backends | Plan certificates, identity provider trust and redirect URLs for your own domain. Managed endpoint settings do not carry over. |
| Audit logs | OpenSearch Security audit logging | Re-enable audit logging and route it to your log platform. Confirm categories and storage for your target release. |
| Index lifecycle policies | Index State Management policies | Export and recreate policies, then confirm their behavior and syntax in the docs for your target release. |
| Ingestion pipelines | Ingest pipelines on ingest nodes, fed by your chosen collector or shipper | Rebuild pipeline definitions and repoint shippers to the new endpoint. Test field mappings with sample events. |
| Dashboards, saved objects and alerting | OpenSearch Dashboards saved objects and alerting monitors | Export saved objects and import them into your Dashboards instance. Recreate monitors and notification channels, then confirm the import method for your release. |
| Cluster sizing and node roles | Dedicated cluster manager, data, ingest and coordinating nodes, with replicas on separate nodes | Managed domain sizing does not translate directly. Size each node role separately and use shard allocation awareness for availability. |
Choosing between Migration Assistant, snapshot and restore, and remote reindexing
Four questions decide which path fits: whether writes must continue during the move, whether the target is a different major version, how much history must come across, and whether the new cluster can read the source snapshot repository. Answer them in that order before you commit to a method. OpenSearch documents four upgrade and migration methods in total, but rolling upgrades does not apply to this move. It is a method for in-place upgrades of a self-managed cluster, so it does not help when you are changing hosting models. The three paths that do apply are Migration Assistant, snapshot and restore, and remote reindexing, and each one answers those four questions differently.
Migration Assistant is the path to examine first when writes must continue during the move or when the target is a different major version. Its documentation describes moving workloads across several major versions in one step, for example from Elasticsearch 6.8 to OpenSearch 2.19, and it supports live traffic capture for low or zero downtime. Live capture records incoming requests against the source so they can be replayed on the target after historical data is copied, which is why it has more moving parts than the other two paths. Confirm in the Migration Assistant documentation which source types and access patterns apply to your managed domain version before you plan network access, because support depends on the source version and on how the source can be reached.
Snapshot and restore fits a repository-based copy when you need the full history, the source can be quiet for a cutover window, and the new cluster can read the same snapshot repository. The main work is access. Both sides need to reach a repository location, the restore side needs credentials and permissions for it, and you must confirm that the target version can restore the snapshot the source produces. Plan the cutover around a write freeze, because a snapshot captures a point in time and anything written after it must be handled separately. Ask your team to measure the size of the largest indices in your own environment, since that measurement, not a general estimate, sets the length of the window.
Remote reindexing suits selected indices, not a whole cluster. It pulls documents from the source over the network into indices you create on the target, which makes it useful when only a few indices need to move, when you want to reshape the data during the move, or when repository access is not possible. Its limits are network throughput and the need to manage writes that land during the copy. Before you choose it, confirm that the target can reach the source endpoint and that the source access controls allow the reindex operation for the account you use. Whichever path you pick, none of the three moves the security, ISM or pipeline configuration, so inventory those early.
Which documented migration and install paths to use for the target cluster
OpenSearch documents four ways to move data and workloads, and eight ways to install the target cluster. Choose the migration path first, because it determines what moves, what you must rebuild and which network routes and credentials you need. The install method then follows from how your team already operates infrastructure.
Migration Assistant
Migration Assistant is the documented path for moving a managed domain into self-hosted OpenSearch with live traffic capture, which supports low or zero downtime cutovers. It can move workloads across several major versions in one step. Confirm the supported source and target versions, the exact deployment steps and any required network access in the linked migration docs before you plan the cutover window. Expect that it moves indexed data and traffic, not your security configuration, ISM policies or ingest pipelines.
Snapshot and restore
Snapshot and restore copies index data to a snapshot repository and restores it into the target cluster. This path requires a repository both clusters can reach, such as an object storage bucket, along with the credentials and network routes to it. Confirm with the migration docs which repository types and source-to-target version combinations are supported. Snapshots do not carry the security plugin's roles, users or tenants, so plan to recreate those separately.
Remote reindexing
Remote reindexing pulls documents from the source cluster over the network and writes them into the target, which is useful for smaller indices or when you need to transform data during the move. It requires a route from the target to the source endpoint and credentials with read access to every index in scope. Confirm the allowed remote hosts and any version constraints in the migration docs. Mapping, settings and any source-side ingest pipelines still need to be reviewed and rebuilt on the target.
Docker installation
Docker is the documented way to run a single-node or multi-node test cluster quickly, and it suits proof-of-concept and development targets. For production, confirm the image tags, the required kernel and memory settings and how you will persist data volumes and certificates. You must provide a container host, storage that survives restarts and the TLS material the security plugin expects. The installation guide covers the exact commands for each supported version.
Helm and Kubernetes operator
Helm charts and the OpenSearch Kubernetes Operator both deploy the target cluster onto a Kubernetes environment you control. The operator manages cluster lifecycle declaratively, while Helm gives you a chart-based release you upgrade manually. Confirm the chart and operator versions that match your target OpenSearch release, and check how each handles storage classes, node roles and certificates. You must provide a Kubernetes cluster with persistent storage and network policies that allow Migration Assistant or reindexing traffic where needed.
Tarball, RPM, Debian and Ansible
Tarball, RPM and Debian packages install OpenSearch directly on Linux hosts, and the Ansible playbook automates the same host-based setup across a fleet. Choose these when your operations standard is package-managed virtual machines or bare metal rather than containers. You must provide the host operating system, service accounts, data and log directories, and JVM and kernel settings that the install guide specifies. Confirm the playbook's supported versions and variables in the install docs before adopting it.
What does not move with the data and how to rebuild it
When teams migrate from Amazon OpenSearch Service to self-hosted OpenSearch, the index data and its mappings are only part of the job. Security roles, role mappings, authentication backends, TLS material, audit settings and pipeline definitions do not travel with the index data, so each one needs an owner and a rebuild plan. Start by inventorying every item in your own domain before estimating work. List each role, mapping, identity provider connection, certificate, pipeline, dashboard, monitor and client application, and record where each one is defined today. The total differs for every domain, and an inventory that skips applications and senders is the most common reason cutover estimates turn out wrong.
Security roles and access control are where most of the rebuild lands. Role definitions and role mappings are normally exported, reviewed and reapplied in the target, then tested with actual identities. Confirm which AWS IAM principals currently sign requests against the domain, and map each one to a role the self-hosted cluster can enforce. Document-level security, field-level security and field masking need the same treatment. Compare each restricted index against the restriction it carries today, because a filter that was scoped in a managed console may not carry across unchanged. Review impersonation grants too, since they are often held by service accounts that nobody on the current team remembers creating.
Authentication, TLS and audit logging need separate planning. The OpenSearch Security plugin supports SAML, OpenID Connect, Active Directory, LDAP, Kerberos and JSON Web Token backends, so the first decision is which backend the self-hosted cluster will use and how it connects to the identity provider already in place. Node and client TLS certificates are not supplied by a data migration, so certificate authorities, trust chains, renewal ownership and hostname entries must be settled before cutover. Audit logs are also configured per cluster. Decide what must be recorded, where the logs go and how long they are kept, and check that scope against your own retention obligations before the first production write.
Lifecycle policies, pipelines, dashboards, monitors and clients are where cutovers usually break. Index State Management policies, ingestion pipelines and their senders, saved objects in OpenSearch Dashboards, and alerting monitors with their destinations should each be exported, recreated and validated against the target, with a named owner for each. Applications and agents often hold endpoint URLs, credentials and index names that must be updated and tested in staging first. Confirm that each lifecycle policy still matches the retention you intend, that a sample monitor reaches its destination, and that every sender writes successfully. Record these results so the cutover runbook reflects what was actually verified.
The migration sequence from inventory through parallel run and decommission
This sequence moves a managed Amazon OpenSearch Service domain to a cluster you run, with data, access and configuration checks completed before any client changes. Each step ends with a record the team can review, so the cutover decision rests on evidence. The managed domain stays in service until the parallel run and rollback path are proven.
Inventory the managed domain completely
Record the OpenSearch version, the index list with mappings and data volume, the snapshot repository and schedule, the roles and access policies, lifecycle policies, ingest pipelines, dashboard saved objects, and every client, integration and alert that reads from or writes to the domain. Confirm with the migration tooling documentation which configuration it carries over, and mark everything else for rebuilding. Done when the platform, security and application owners have reviewed the inventory and each item is marked as migrated, rebuilt or retired.
Design the target topology
Size the self-hosted cluster around dedicated cluster manager nodes, and plan data, ingest and coordinating node roles based on the workload in the inventory. Place replica shards on separate nodes and configure shard allocation awareness across the failure domains you control, such as zones or racks. Document the failure scenarios the cluster must survive. Done when the topology diagram and node role plan are approved and the sizing matches the inventoried data volume and expected growth.
Build and secure the target cluster
Install the target with the method your platform team operates, such as Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian packages or the Ansible playbook. Configure the Security plugin with TLS for node and client traffic, your identity backend (SAML, OpenID Connect, LDAP or Active Directory), role-based access and audit logs. Recreate the source roles, including any document-level or field-level rules the inventory lists. Done when security testing confirms that anonymous access is blocked and each migrated role matches its approved definition.
Rebuild lifecycle, pipelines and dashboards
Recreate the Index State Management policies, ingest pipelines, index templates, snapshot repository and OpenSearch Dashboards objects on the target from the inventory, then test each one. Run each lifecycle policy against test indices so rollover, transitions and deletion behave as the source did. Keep every rebuilt artifact in version control with a reviewer. Done when each artifact produces the same result as its source on the same test data.
Run a pilot migration of representative indices
Select indices that cover each mapping type, lifecycle state, size class and access pattern in the inventory. Migrate them with Migration Assistant or the method your team chose, then validate document counts, field mappings, sample queries and user access against the source. Record each mismatch, fix its cause and repeat the pilot from a clean target. Done when a full repeat completes with a validation log that shows no unexplained differences.
Start the parallel run and compare results
Start the parallel run with live traffic capture or dual writes, whichever the chosen migration method supports, so the target receives the same data as the source. Compare search results, dashboard panels and alert behavior on both clusters over a window you agree in advance, long enough to include scheduled alerts and the common query patterns. Investigate every difference. Done when the comparison shows only differences that were agreed in advance and every alert fires on both clusters.
Cut over clients and ingestion with rollback
Move clients and ingestion endpoints to the target in stages, keeping a documented path back to the managed domain until the agreed checks pass. Write the rollback steps, their owner and the decision point before the change window opens. Rehearse the rollback on the pilot environment. Done when every client reports healthy against the target, ingestion lag stays within the threshold you set, and the rehearsed rollback has been recorded.
Decommission the managed domain after retention
Keep the managed domain and its final snapshots for a retention period you set with your legal, compliance and platform owners. Revoke access, remove endpoints from client configuration and DNS, then delete the domain once the retention period has ended. Confirm that the retained snapshots still meet your retention policy and can be restored if needed. Done when the deletion and the retention decision are recorded in the change log and the decommission evidence is filed.
What drives the cost and duration of an OpenSearch migration from AWS
This table lists the drivers that change the effort and schedule of moving an Amazon OpenSearch Service domain to a self-hosted cluster, with the reason each one matters and what to request in a quote. No duration or price figure is supplied for this page, so any quote follows from a written scope and a completed inventory of your domains. Use your own inventory to rank the drivers before you request a proposal.
| Driver | Why it changes effort | What to ask for in a quote |
|---|---|---|
| Data volume and index count | Snapshot, transfer and validation runs take longer as stored data, index count and shard count grow. | Stored data size, index and shard counts, and the transfer path from the AWS account to your network. |
| Source and target version gap | Migration Assistant can cross several major versions in one step, but mappings, plugins and query behavior still need testing for each gap. | Confirmed source engine version, target OpenSearch version, and a review of plugins and mappings. |
| Live traffic and write freeze | Live traffic capture supports low or zero downtime, but replay, comparison and cutover checks add work as write rates rise. | The write freeze window you accept, the read and write traffic profile, and the cutover and rollback steps. |
| Ingestion pipelines and clients | Each producer, pipeline and application client must be repointed, with its endpoints, credentials and certificates tested. | A list of pipelines and clients with owners, and the endpoints, credentials and certificates that change. |
| Roles and identity integrations | Access control is not carried over, so roles, role mappings and identity backends such as SAML, OpenID Connect or LDAP must be rebuilt and tested. | Number of roles and mappings, the identity providers in scope, and whether document or field-level security applies. |
| Lifecycle and retention policy | ISM policies, snapshot repositories and retention rules are outside the data move and must be recreated and checked against retention needs. | Count of ISM policies, index patterns, snapshot schedules and retention rules to reproduce, with the owner of each. |
| Dashboards and alerting volume | Dashboards, saved objects, monitors and notification channels need export, remapping and verification by the users who depend on them. | Number of dashboards, alerting monitors, notification destinations and the teams who rely on each. |
| Topology, high availability and network constraints | Dedicated cluster manager nodes, replicas on separate nodes, allocation awareness, offline package sourcing and egress limits each add design and approval steps. | Target node roles, failure domains, replica policy, approved install method, network diagram and evidence expectations. |
| Your own staffing | Cutover and testing need named owners for indexes, security, pipelines and on-call support, and gaps in those roles extend the schedule. | Which tasks are assumed to be done by your team, which tasks the partner performs, and the handover plan. |
What usually goes wrong in a managed-to-self-hosted cutover and how to prevent it
Most failed cutovers from Amazon OpenSearch Service trace back to settings the managed service handled for you and that a snapshot restore does not carry over. The cards below cover the configuration, data and operating gaps to close before traffic moves, so each one has an owner and a check.
Security settings left open or too broad
Managed domains often sit behind AWS IAM and network policies that do not move with the data, so a self-hosted cluster can come up with HTTP reachable from places it should not be, or with roles copied too generously. Before cutover, rebuild TLS for node and client traffic, map users and groups through the Security plugin's authentication backend, and write role mappings for each application user. Then test that each role can reach only its indices, and that unauthenticated requests are refused from every network segment.
Index lifecycle policies not recreated
Index State Management policies, rollover aliases and retention rules are configuration, so they do not arrive with the indices. Retention can change without any error: indices that were deleted on schedule in the managed domain may persist, or the reverse. List every policy and its attached indices in the source domain, recreate each one in the target, and confirm with a dry run on a copy that the same indices move through the same states and deletion dates.
Ingestion sources still pointed at the old endpoint
Log shippers, Data Prepper or OpenTelemetry collectors, ingest pipelines, application clients and scheduled jobs each hold an endpoint and credentials for the managed domain. Any source left unchanged keeps writing to the old domain after the switch, which can look like a healthy target that is simply receiving less data. Inventory every writer and reader, change endpoints and credentials in a planned order, and watch document counts on both sides until the old domain shows no new writes.
Mapping and analyzer differences
Field mappings, dynamic templates, analyzers, normalizers and index settings are copied as definitions, but a reindex or Migration Assistant transform can still change how text is tokenized or how numeric and date fields are typed. The result is search that returns different hits, sorts or facet counts without any failed request. Compare the source mappings and analyzers with the target, run a fixed set of representative queries against both clusters, and record the differences that business users would notice before sign-off.
Underestimated volume, snapshot time and rollback
Snapshot and restore time, backfill duration and the storage needed on the new cluster grow with the size of the indices, not with the number of nodes. Teams often plan the cutover window from a rough estimate and discover the backfill is still running when the window closes. Measure the current index size and document count, run a timed snapshot restore or backfill on a representative subset, and keep the source domain intact and writable long enough to serve as the rollback path.
Unclear ownership after handover
After cutover, someone must own patching, certificates, backups, snapshot retention, upgrades and the decision to roll back, and that role changes when AWS no longer runs the control plane. Name an owner for each area before go-live and write down who can approve a rollback. Track OpenSearch version maintenance dates as part of that ownership: OpenSearch 1 reached end of life on May 6, 2025, so confirm the source version and the target version's support window before the handover is signed.
Questions teams ask before moving off Amazon OpenSearch Service
What drives the cost of moving off Amazon OpenSearch Service?
Cost has two parts: a one-time migration project and the recurring cost of running the cluster yourself. The one-time part covers planning, setting up Migration Assistant, rebuilding security, ISM and pipeline configuration that does not move automatically, testing, and cutover. Whoever performs that work, your staff or a partner, is paid for it. The recurring part covers compute, storage, network, backups and load balancing in your own accounts or data centers, plus the staff time to operate, patch and upgrade the cluster. OpenSearch software is licensed under Apache 2.0, so no license fee appears in the recurring line, but confirm any third-party plugins or tooling you add. The main drivers are data volume, retention period, number of domains and indices, the count of ISM policies and pipelines, identity integrations, and the availability design. Ask any quote for an itemized scope that separates one-time and recurring costs and states the assumptions about data volume and downtime.
How long does a migration from Amazon OpenSearch Service take?
The duration depends on the scope of your domains, and no single timeline fits every environment. The main drivers are the volume of data to move and the bandwidth of the transfer path, the number of indices and domains, and whether you need live traffic capture to keep downtime low or zero. Time also grows with the amount of security, ISM and pipeline configuration that must be rebuilt by hand, and with how quickly your identity, network and data owners can approve changes. The length of your test window and the cutover plan add further time. Confirm the timeline in the written scope before work starts. A useful scope lists phases, milestones, dependencies between them, and the responsibilities your team carries at each step, so you can see which delays would move the end date.
What does our internal team need to provide for the move?
The move depends on several things only your organization can supply. Expect to provide the following:
- Source access: read access to the managed domains, including their configuration, index settings, roles and snapshot repositories.
- Network routes: firewall rules and routing between the AWS source and your target infrastructure, plus DNS changes for cutover.
- Identity owners: the people who run your SAML, OpenID Connect, Active Directory or LDAP sources and approve role mappings.
- Data owners: staff who classify indices, confirm retention periods and sign off on which data moves.
- A test window and a cutover window, with a rollback decision maker named in advance.
Assign one technical lead on your side to answer questions quickly. Delays usually come from slow approvals and unclear data ownership, so settle those early.
Can our own team migrate from Amazon OpenSearch Service alone?
Yes, for a simple domain with documented steps, a team can usually do the move alone. A simple domain has few indices, no custom plugins, standard security roles and a documented migration path. Your team needs Linux administration, package or container installation, TLS and certificate handling, OpenSearch Security configuration, cluster sizing, and hands-on experience with Migration Assistant or snapshot and restore. Plan for at least one engineer to work through test and cutover, plus ongoing time for patching and upgrades after go-live. Complex environments with many ISM policies, SAML integration, custom ingest pipelines or strict audit requirements take longer and carry more risk. In those cases, a partner working to a written scope can reduce that risk, and your team keeps the ability to run the platform afterward.
Does OpenSearch have a paid enterprise edition?
The OpenSearch FAQ does not describe a paid edition. All software in the OpenSearch project is released under the Apache License, Version 2.0. The OpenSearch Software Foundation is a Linux Foundation project, and it is not involved in technical oversight of the OpenSearch project. Your costs after moving are therefore infrastructure, staff time and any services you choose to buy, not a license fee for the project software. Before you assume a commercial offering exists from any company, confirm it directly with that company and ask for its terms in writing. Also note that Amazon OpenSearch Service is a managed AWS offering with its own pricing, so compare total running costs in your own environment, not the managed service's list terms.
Which OpenSearch version should we target after leaving AWS?
Target the newest minor release in a line that is still in maintenance, then confirm its support end date before you commit. OpenSearch 3.9.0 was released on September 29, 2026, and 3.8.0 on August 4, 2026. The project targets a new minor version about every eight weeks, so check the releases page for the current latest version on the day you plan. Versions stay in maintenance until the next major version enters maintenance or one year passes, whichever is longer. Maintenance releases receive bug fixes and security patches but no new features. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release. Also check that your source version can migrate in one step, because Migration Assistant can move workloads across several major versions.
Will DeployOpen certify our OpenSearch environment as compliant after the move?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies issue those. Our work is to configure and document the platform so the evidence exists and can be retrieved. That can include TLS settings, role-based access control and audit logging, retention settings in ISM, backup records, and change records. Ask your auditor early which evidence they need and in what format, so the configuration can be built to match. Confirm the scope of any assessment with the assessor before the move starts, because the controls they test depend on your environment, not on the software alone.
How DeployOpen scopes, delivers and supports the migration
DeployOpen plans the move from Amazon OpenSearch Service to OpenSearch you run in infrastructure you control, using Migration Assistant for the data and traffic path. We also rebuild the security, index state management and pipeline configuration that the managed service does not carry across. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory domains, indices, index templates, ISM policies, snapshot repositories and ingest pipelines on the managed domain.
- Map the access model, including IAM-based access, fine-grained access control roles and any SAML or OpenID Connect sign-in you need to keep.
- Agree in writing the target OpenSearch version, deployment method and cutover approach, such as live capture or a planned write freeze.
How we build
- Stand up the target cluster with dedicated cluster manager nodes, replicas on separate nodes and shard allocation awareness.
- Configure the Security plugin with TLS, role-based access, audit logging and the authentication backend your directory uses.
- Run Migration Assistant in a staging copy first, then test data integrity, query behavior and dashboard rendering before cutover.
How we hand over
- Deliver the rebuilt ISM policies, security roles, pipelines and snapshot schedules as versioned configuration with a written record.
- Document the cluster topology, backup and restore steps, and the rollback path used during cutover.
- Walk your operations and security teams through runbooks for upgrades, certificate rotation and capacity changes.
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover, with scope agreed separately.
- Plan upgrades against OpenSearch maintenance and end-of-life dates confirmed on the official releases page at the time of work.
- Confirm with your team which patch and security update process applies to your environment before the retainer starts.
