Why open source product search for ecommerce needs its own plan
Product search is a sync and merchandising problem as much as an engine choice. A store's catalog changes daily, prices and stock move through the day, and promotions must appear in search results as soon as they go live, not after a nightly reindex. The search engine is only one part of that chain. The commerce platform owns the source data, a connector or indexing job moves it into the engine, and a merchandising team decides which products rank for which terms. Before comparing Meilisearch, Typesense or OpenSearch, the operator should map who owns each link in that chain and how a change in the catalog reaches the index in minutes.
The right engine depends on three things: the commerce platform, the catalog size and who manages the rules. Magento Open Source, WooCommerce, Saleor, Medusa and Sylius each expose products through different APIs and plugins, so the connector work differs even when the engine is the same. A team with a large catalog and a Magento or Saleor backend, where search engineers can run clusters, may lean toward OpenSearch for its wide query features and Apache License 2.0 terms. A smaller team that wants typo tolerance, facets and synonyms with a lightweight operational footprint may find Meilisearch or Typesense easier to run, with Typesense offering Raft-based clustering for higher availability. Merchandisers who edit boosts and pinned results every day need a tool and a workflow for that, not only an engine. Confirm each candidate against your own catalog size and query volume, because these facts depend on your environment.
What a self-hosted product search build must satisfy
This table maps the requirements an online store usually brings to product search, the source of each one, and what it means for the build. Read it as a checklist: each row names the owner of the requirement and the platform capability that can meet it, so you can confirm fit before choosing Meilisearch, Typesense or OpenSearch.
| Requirement | Source of the requirement | What it means for the build |
|---|---|---|
| Typo tolerance and search-as-you-type | Shopper experience | Shoppers misspell brand and product names. Confirm typo tolerance settings on your own sample queries (Meilisearch and Typesense both list it as a core feature), and test short queries and model numbers separately. |
| Facets and filters (size, colour, price, brand) | Shopper experience and merchandising | Attributes used for filtering must be declared up front. In Meilisearch they are set as filterable attributes, and in Typesense and OpenSearch they are defined in the collection or mapping. Plan the attribute list with the catalog team before indexing. |
| Sorting by price, rating or newness | Merchandising policy | Sort fields must be declared as sortable in Meilisearch or typed correctly in the schema of the other engines. Agree the default sort order and whether shoppers can change it. |
| Synonyms and query rules | Merchandising policy | Synonyms such as trade names and regional terms need an owner and a change process. Typesense converts query rules into its Overrides API during migration, so confirm which rules your current search uses before moving them. |
| Pinned and boosted products | Merchandising policy and commercial goals | Pins and boosts change the ranking of live results and need review rights. Confirm how each engine ranks, pins and boosts, and whether your current rules have an equivalent. Some Algolia features have no direct Meilisearch equivalent, so test them. |
| Index freshness after price or stock changes | The store's operating constraint | Price and stock changes must reach the index quickly, or shoppers see wrong prices and sold-out items. Decide the sync method (event-driven or scheduled batch), set a maximum acceptable lag, and test it against the Magento, Saleor or Medusa catalog events you rely on. |
| Access control for admin and reporting data | Data protection and internal policy | Merchandisers, support staff and analytics users need different access. OpenSearch offers role-based access control, field-level security and audit logs through its Security plugin. Confirm equivalent controls in Meilisearch and Typesense, which may rely on API keys and network controls instead. |
| Handling of query logs and customer data | Data protection | Search queries can reveal personal data and purchase intent. Decide what is logged, how long it is kept, who can read it and how it is deleted. Confirm the retention and masking options of your chosen engine and of any analytics add-on. |
| Uptime during peak sales periods | The store's operating constraint | Search outages during campaigns cost sales. Typesense recommends a highly available 3-node or 5-node Raft cluster for production. Plan replicas and failover for OpenSearch, and confirm replication options for Meilisearch by edition, then load test before peak dates. |
Which search engine fits which store
The three engines differ less in what they search than in what they cost to run, how they license the server, and how much of the merchandising and analytics layer you must build yourself. Match each engine to your catalog size, memory budget, team skills and the features you need on day one.
Meilisearch for focused catalogs
Meilisearch's Community Edition is MIT licensed, and its README lists typo tolerance, filtering, faceted search, hybrid search and multi-tenancy. For a single store with a modest catalog and a small team, it is often the simplest self-hosted starting point. Check that the Enterprise Edition features you need are actually in the Community Edition, since that edition is not permitted in production without a commercial agreement. Confirm how your chosen version handles index size and reindexing at your catalog scale before committing.
Typesense for memory-planned search
The Typesense server is GPL-3.0, which lets you run modified server code internally without publishing changes as long as you do not distribute it. It keeps data in memory and supports Raft clustering, so the memory budget is the main design input. Budget two to three times the size of the searchable fields for keyword search, plus 7 bytes per vector dimension if you add semantic results. Production setups should use a 3-node or 5-node cluster. Typesense also documents an Algolia migration path, but its vendor-stated feature parity of about 85% leaves out server-side A/B testing, event tracking and personalization.
OpenSearch for shared search and analytics
OpenSearch is released under Apache License 2.0, with no paid edition described in its FAQ. It is a fork of Elasticsearch 7.10 and is wire-compatible with it, which helps if your team already runs Elasticsearch tooling or wants search logs and dashboards alongside the catalog index. Its Security plugin provides role-based access control, field-level security, field masking, audit logs and TLS, which matters when merchandisers, support staff and partners see different product or customer fields. Expect heavier operations than the other two engines: node roles, replicas, shard sizing and version upgrades all need an owner.
Choosing by catalog size and memory
Catalog size and memory budget usually decide the shortlist before features do. Measure your searchable fields, the number of product variants, and the share of catalog that will carry embeddings. A small catalog with a tight RAM budget points toward Meilisearch, a memory-planned catalog with clustering needs points toward Typesense, and a large catalog that must share a cluster with logs or other indexes points toward OpenSearch. Ask each candidate for a load test using your real catalog export and your peak query rate before you choose.
Team skills and operating load
Each engine asks for different operating skills. Meilisearch and Typesense have small, focused server surfaces that a platform team can run with routine backup, upgrade and monitoring tasks. OpenSearch needs people who understand cluster state, shard allocation and security plugin configuration. Whoever runs the engine after go-live must also own index sync from Magento, Saleor or Medusa, reindexing and version upgrades. Ask partners to name who covers each of these tasks in the support terms.
Analytics and personalization you still build
None of the three engines provides a full merchandising analytics or personalization layer out of the box. Typesense documents missing server-side A/B testing, built-in event tracking and default recommendations, and Meilisearch's Algolia migration guide notes that some Algolia parameters, such as aroundPrecision and disablePrefixOnAttributes, have no equivalent. Decide early whether click and conversion tracking, ranking experiments and recommendations will come from your storefront, a separate analytics tool or a partner-built pipeline, and confirm the data path before the search engine is chosen.
How product data stays in sync with Magento, Saleor or Medusa
The search index is only as current as the pipeline that feeds it, so the first decision is how product changes leave the commerce platform and reach the search engine. Plan two paths from the start: a one-time bulk export of the full catalog, and a continuous stream of incremental changes. Bulk loads are where most of the early effort goes. Existing Algolia migration tooling shows the pattern: Meilisearch documents importing records with addDocumentsInBatches in batches of 100,000, and Typesense documents importing JSONL through its documents import endpoint with action=upsert. Your team should confirm whether the store's catalog API, webhooks or event hooks can supply a complete export and change feed for Magento, Saleor or Medusa. Those capabilities depend on your version, extensions and customizations, so verify them with the platform team before estimating the pipeline.
Incremental updates need a clear rule for each field type. Price, stock and availability change far more often than names or descriptions, and they often come from different services, such as a pricing engine or warehouse system. Decide which fields the search index must reflect within seconds, which can lag by minutes, and which are only refreshed in the nightly full rebuild. Variants need a deliberate model: one indexed record per variant suits size and colour filters, while one record per parent product with variant attributes suits browsing but makes stock per variant harder to show. Category trees should be flattened into the fields your facets use, and any merchandising rule (pinned products, synonyms, promoted results) should live in configuration that survives a reindex. Deletions are the most often missed case. A product removed or disabled in the store must also be removed from the index, or customers will see items they cannot buy. Ask for a reconciliation job that compares store and index IDs on a schedule and reports drift.
How merchandising rules and store structure change the engine choice
A single store with one catalog needs the fewest controls. Merchandisers usually want synonyms for brand names and product jargon, pinned products for campaigns, and boosts that favor in-stock or high-margin items. All three engines can hold one index per catalog, so the decision depends on how rules are authored, tested and maintained. Teams moving from Algolia should start with the mapping guides. Meilisearch's Algolia migration guide maps index settings to its own settings and states that a few Algolia parameters have no equivalent. Typesense's migration guide says query rules convert to its Overrides API, and it notes that some Algolia features, such as server-side A/B testing and built-in personalization, are missing.
- Synonyms: list the terms shoppers actually type, including brand nicknames and size shorthand, and confirm how each engine stores and updates them.
- Pinned results: confirm whether the engine can fix a product to a position for a given query, and test whether Typesense Overrides cover the campaigns you run.
- Boosts: test stock status and margin as ranking inputs, and confirm the ranking and sorting configuration for each engine.
- Migration gaps: Meilisearch's guide lists aroundPrecision, restrictHighlightAndSnippetArrays and disablePrefixOnAttributes as having no equivalent, so check whether your front end depends on them.
Before writing a migration plan, run your top twenty queries against a copy of the catalog and confirm that each rule produces the expected result.
An operator that runs several brands or storefronts often shares one product catalog across them. Each brand may need its own synonyms, pinned products and ranking preferences, and some products may appear in one storefront only. Meilisearch's README describes multi-tenancy that personalizes results for any number of application tenants, which makes it a strong candidate to test for this model. Typesense and OpenSearch also support this pattern, but the design choice is different. Separate collections or indexes per brand are simpler to reason about, while a shared index with scoped filters uses less storage. Typesense's system requirements guide says keyword search typically needs two to three times the size of the searchable fields in RAM, so every duplicate per-brand index multiplies that memory cost.
- Shared catalog: keep one product source of truth and derive each brand's view with filters, not copies, where the engine supports it.
- Brand-level rules: confirm whether synonyms and pinned results can be scoped to one brand without affecting others.
- Memory planning: model RAM for each option, because per-brand indexes repeat the searchable fields.
- Access boundaries: OpenSearch's document-level and field-level security can restrict what a given role sees, which matters if brands must not see each other's internal data.
Ask each vendor and integrator to demonstrate a brand-scoped rule change on your catalog, including how it is audited and rolled back.
A marketplace shares one search experience across many sellers, so results must respect seller boundaries and ranking rules must stay consistent. Seller-level synonyms are rarely appropriate because they can change how other sellers' products surface. Pinned results and boosts need clear governance, because a paid placement or seller promotion can distort ranking for everyone. The engine choice depends on how well seller visibility can be enforced inside the search layer. OpenSearch documents role-based access control, document-level and field-level security, and field masking, which are the most explicit access controls among the three options. Meilisearch and Typesense require you to confirm whether scoped API keys, filters or per-seller indexes can enforce the same boundaries for your data model.
- Seller visibility: decide whether suspended or unverified sellers are excluded at index time, at query time or both, and confirm which engine enforces that reliably.
- Promotion governance: define who can pin or boost products and how each change is logged.
- Seller data protection: keep internal seller fields, such as cost or contract terms, out of the search index or mask them.
- Ranking fairness: document the ranking inputs so the marketplace can explain results to sellers and to auditors.
Confirm with each candidate how seller-scoped access is tested, and whether the query logs that record seller-level behavior are kept in your environment.
How a product search rollout moves from pilot to peak season
The sequence turns a catalog and its merchandising rules into a self-hosted search service that is tested under load, cut over in stages and can be rolled back before a peak trading period. Durations depend on the scope agreed in writing before work starts.
Audit the catalog and attributes
The team inventories product counts, variants, attributes, price and stock fields, locales, currencies and the fields shoppers actually filter and sort by. DeployOpen works with your catalog owners and the platform team to document where each field lives in Magento, Saleor, Medusa or the commerce system in use. The step closes with a written catalog profile that lists record counts, update frequency and the attributes that need to be searchable, filterable or sortable.
Select and size the search engine
Using the catalog profile, the team compares Meilisearch, Typesense and OpenSearch against required features such as faceting, synonyms, hybrid search and multi-tenancy, along with expected traffic and high-availability needs. Sizing uses the vendor memory guidance for the chosen engine, checked against your own record sizes and test data. The output is a signed platform decision and a sizing note that states the node count, memory and storage assumptions to be verified in testing.
Design the index schema and facets
The team maps catalog attributes to searchable, filterable and sortable settings, defines ranking rules, and decides how variants, bundles and localized fields are stored in each index. Facet choices are tested against real category pages so that filter counts and sort orders behave as merchandisers expect. The step ends with a versioned schema file and a set of sample queries with expected results that will be reused during testing.
Build the catalog sync pipeline
Engineers build the job or event pipeline that reads products from the commerce platform, transforms them into search documents and writes incremental and full updates. The pipeline covers deletes, price and stock changes, and a rebuild path for recovery. It is complete when a product edit in the commerce back office appears in search within the freshness window your business has agreed, and when a full reindex runs from a clean state without manual steps.
Migrate synonyms and merchandising rules
Existing synonyms, pinned results, boosts and redirects are exported from the current search tool and mapped to the target engine's equivalents. Some rules from hosted platforms, such as Algolia rules, have no one-to-one mapping and need a documented workaround or a business decision to drop them. Merchandisers review every migrated rule against a list of key queries. The step closes with a rule register that shows each source rule, its target, and its approval status.
Integrate the storefront search interface
Front-end engineers connect the storefront to the new search API, using an InstantSearch adapter where the existing widgets are built on Algolia InstantSearch. Developers confirm that autocomplete, facet panels, pagination, empty-result handling and accessibility behave correctly on desktop and mobile. Analytics events are wired to the reporting system you already use. The step is done when the storefront passes functional tests on each supported browser and device class.
Test load and failover
The team runs load tests that replay realistic query logs and concurrent catalog updates, then simulates node failures and a full reindex during traffic. For Typesense, this covers the Raft cluster behavior with three or five nodes, and for OpenSearch and Meilisearch it covers the replica and recovery setup in your environment. Results are compared with the sizing note. The step closes with a test report, agreed latency and error thresholds, and a list of accepted risks signed by the business owner.
Cut over in stages with rollback
Traffic moves to the new search service in stages, starting with a small share of storefront sessions and extending as error rates, relevance metrics and conversion data stay within agreed limits. The previous search service stays available and the cutover runbook names the switch, the owner who can trigger it and the criteria for rolling back. Rollback is rehearsed before the change window. Peak-season readiness is confirmed only when the rollback has been tested and the change freeze is in place.
What do stores ask before self-hosting product search?
What drives the cost of self-hosting product search for a store?
The cost follows catalog size, how often prices and stock change, how many storefronts search the same index, and how much memory the engine needs for facets and vectors. Infrastructure is a recurring cost you pay to your cloud or data center provider. Implementation, catalog connectors, relevance tuning and hardening are one-time costs paid to whoever builds it, whether that is your team or a partner. Ongoing upgrades, monitoring and on-call support recur. Ask any quote to split these lines, state the catalog size and update frequency it assumes, and say what support terms apply after go-live.
How long does a product search implementation usually take?
Duration depends on the number of catalog sources, how clean the product data is, how many facets and merchandising rules the business wants at launch, and whether the storefront already uses an InstantSearch-style front end. A single store with one clean catalog and a stock front end is a smaller job than a multi-brand marketplace with several storefronts and custom ranking. No timeline in this page is a fixed commitment. Ask for a written scope with phases, the assumptions behind each phase and the acceptance tests that close each one.
What does the store's team need to provide for the project?
Four inputs matter most:
- Read access to the catalog source, such as the Magento, Saleor or Medusa database or API, plus a sample export with real product variants
- A named merchandising owner who can approve synonyms, pinned results and boosts
- A product or search owner who decides which facets and sort orders go live first
- Test traffic, including a list of real customer queries from the search logs, so relevance can be measured before launch
Without these, the team spends the project guessing at relevance and rework grows.
Can an in-house team run self-hosted product search alone?
Often yes, if the team already operates containers, has someone who understands the catalog data model and can carry on-call duties. The engine is open source, and the self-hosting option includes full infrastructure control with no usage limits, but operators handle updates, backups and scaling. The harder parts are usually the sync pipeline from the commerce platform, relevance tuning and keeping index settings aligned with each release. Decide early which of these the internal team will own, and whether an implementation partner will cover the build, the handover or ongoing support under a written agreement.
Does Meilisearch Cloud or Typesense Cloud pricing change the decision?
Hosted pricing is one input to the decision, not the whole answer. Meilisearch's pricing page lists Meilisearch Cloud starting at $20 per month with a 14-day free trial and usage-based or resource-based billing, and gives an example base plan at $30 per month for 100K documents and 50K searches. Typesense Cloud offers dedicated clusters with no limits on records or operations, sized from 0.5 GB to 1024 GB of memory across three to seven nodes, with bandwidth billed separately. Compare these figures with your own catalog size, query volume and data residency requirements, and with the infrastructure and staff time a self-hosted setup needs.
How do we move from Algolia to a self-hosted engine?
Treat the migration as a data export, a settings mapping and a front-end adapter change. Meilisearch documents an export with Algolia's browseObjects method and an import with addDocumentsInBatches in batches of 100,000. Its migration guide maps attributesForFaceting to filterableAttributes and NeuralSearch to hybrid search with embedders, and notes that aroundPrecision, restrictHighlightAndSnippetArrays and disablePrefixOnAttributes have no equivalent. Typesense exports with the Algolia CLI as JSONL, maps objectID to id, and converts query rules to its Overrides API, and it reports about 85% feature parity, with server-side A/B testing and built-in personalization missing. Confirm which Algolia features your store actually uses before choosing the target.
What should a quote for product search include?
A useful quote lists the scope in writing: which catalog sources and storefronts are covered, which facets, synonyms and merchandising rules are delivered, how sync is triggered and monitored, and which acceptance tests close the project. It should also state the hosting location, the backup and restore approach, the upgrade process for the search engine, the support hours and response targets, and what is excluded. Fixed-scope work should name deliverables and dates in advance. Ask the partner to explain each assumption about catalog size and query volume, so changes to those assumptions can be priced against the agreed scope.
Does the search index need to stay in sync with product changes?
Yes. Stale prices, out-of-stock items or deleted products damage trust quickly, so the index needs a defined sync path. Common patterns are event-driven updates from the commerce platform, scheduled full rebuilds for reconciliation, and batch imports for large catalog changes. Each pattern has a cost in engineering effort and a failure mode, such as missed events or partial batches. Ask how the sync handles variants, price rules per market and inventory, and how a failed batch is detected and retried.
What to ask an implementation partner about store search
Start with the sync path, because it decides whether shoppers see stock and prices that match the store. Ask the partner which trigger keeps the index current for your platform: a catalog webhook or event, a scheduled delta job, or a full reindex, and what each one does to a product that is deleted, repriced or set out of stock. Ask how a failed batch is retried, how partial failures are reported to your team, and how a stale index is detected before a customer sees it. Ask for the exact fields the sync writes, including any objectID or id mapping, and whether the partner's runbook names an owner for each failure mode.
Next, ask how merchandising rules move and who keeps them after go-live. Synonyms, pinned results, boosts and query rules often live in a store admin screen or a spreadsheet, and they do not map one to one onto Meilisearch, Typesense or OpenSearch. Ask the partner to produce a rule inventory with each rule's status: migrated, rewritten, or dropped with a stated reason. Confirm whether merchandisers will edit rules through a supported tool or through a ticket to engineering, and who approves a change during a promotion. The current Meilisearch Algolia migration guide lists settings that have no equivalent, which is exactly the list to review line by line.
Finally, ask for the load test, the recovery procedure and the commercial terms in writing. Ask which peak traffic profile the test uses, how many concurrent searches it sustains, and whether it runs against the same index size and hardware you will operate. Ask how backups are taken, how a full reindex is run without interrupting search, and how long a restore is expected to take in your environment. Ask what security evidence is delivered for the search cluster, including the API key scopes, network placement, TLS configuration and access logs, and how support, upgrades and retained evidence are priced after go-live. Confirm that the fixed scope names every deliverable, every exclusion and the acceptance criteria before work starts.
What a store can show about its search operations
This sequence turns search from a black box into a set of records a store can produce on request: how the index is configured, how the catalog stays in sync, who holds admin keys, and what testing showed before go-live. DeployOpen prepares these records, and independent auditors decide what they mean for any assessment.
Define the search configuration as code
DeployOpen writes the index settings, including searchable, filterable and sortable attributes, synonyms, typo tolerance rules and merchandising rules, into version-controlled files or scripts. The store's engineers review each change through the same pull request process they use for the storefront. The check that closes this step is a clean rebuild of a test index from the repository alone, with the result matching the production settings. Ask the implementation partner which engine-specific settings must be exported, since Meilisearch separates index settings from search parameters and Typesense uses its own Overrides API for query rules.
Map and document the catalog sync pipeline
DeployOpen documents how product records move from Magento, Saleor or Medusa into the search engine, including which events trigger an update, how deletions are handled, and how batch reindexing runs. The output is a data flow record naming each source table, API or webhook, transformation and target index. The check is a diagram and a short runbook that a store engineer can follow without the original builder. Where a platform is migrated from another search product, the mapping of attributes to filterable and sortable fields is kept as part of this record.
Keep sync and indexing logs
DeployOpen configures the sync job and the search engine to write structured logs for each batch: start and end times, record counts, rejected documents, and error messages. Logs are retained in the store's own log platform for a period the store sets. The closing check is a test run in which a deliberately malformed product record is rejected and appears in the log with its identifier. This gives the store a traceable answer to the question of whether a price or stock change reached the shopper's search results.
Inventory and review admin and API keys
DeployOpen lists every master key, admin key, search-only key and scoped key the setup creates, with the system that holds each one and the owner who approved it. Admin keys are kept out of front-end code and stored in the secrets manager the store already uses. The store runs a recorded access review at an interval it sets, confirming that each key is still needed and that revoked keys are gone. The closing check is a signed inventory dated at the review, showing that no admin key appears in client-side bundles.
Enable audit logging where OpenSearch Security applies
Where the store runs OpenSearch, DeployOpen enables the Security plugin's audit logging and sets role-based access so that indexing services, analysts and the storefront hold separate roles. Authentication is wired to the store's identity provider through the backend the store already uses, such as SAML, OpenID Connect or LDAP. The closing check is a sample audit extract showing who created, changed or read an index, with TLS confirmed on node and client traffic. Meilisearch and Typesense do not offer this same role model, so stores on those engines keep equivalent evidence through key inventories and infrastructure logs.
Record relevance and resilience test results
DeployOpen runs a fixed set of test queries covering typos, synonyms, facet combinations, out-of-stock items and merchandised products, and records the expected and actual results. Load and failover tests are recorded with their configuration, the cluster state before and after, and any errors. The store keeps the test scripts, the dataset version and the sign-off by the merchandising and engineering owners. The closing check is a dated test report that can be rerun after each upgrade, so a regression is visible before shoppers see it.
Assemble the evidence pack and set the review cadence
DeployOpen compiles the configuration repository links, sync runbook, key inventory, audit extracts and test reports into a single evidence index, and agrees with the store who owns each item and how often it is refreshed. This pack supports internal reviews and questions from payment processors, auditors or partners about how shopper data is handled. DeployOpen prepares the evidence and does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the store should confirm with its assessor which records they will accept and in what form.
How DeployOpen scopes and supports product search
Scope is agreed in writing before any work starts. For product search, the written scope should name the engine and edition, the catalog source (Magento Open Source, Saleor or Medusa), the fields and facets to index, the synonym and merchandising rule set, the environments (staging and production), and the hosting account or data center where the search nodes will run. Most engagements are fixed-scope, so the deliverables, acceptance tests and timelines are fixed in that document. Ask for the sync design explicitly: whether catalog changes flow through webhooks, scheduled batch exports or both, how deletions and price changes are handled, and what happens during a full reindex. Those decisions drive most of the later effort, so they belong in the scope before the quote is final. DeployOpen implements the chosen engine and the sync pipeline inside your own cloud accounts, data centers or private network. That includes installing the engine, configuring filterable and sortable attributes, building the indexing job that reads from the commerce database or API, and wiring the storefront search widget to the search endpoint with scoped, search-only API keys. Before go-live, security testing covers the search API itself: authentication of admin keys, exposure of tenant or customer-specific data, injection through query parameters, rate limiting and the behavior of the index under malformed input. Confirm with the partner which test cases, tools and report format are included in the fixed scope, and who fixes findings and retests them. After go-live, the setup is documented so your own team can operate it: architecture, configuration files, key rotation steps, backup and restore procedures and the runbook for reindexing. Ongoing support, version upgrades and continuous testing are available as retainers, so you can decide whether to keep those tasks in-house. Ask any partner to state the response expectations, upgrade cadence and what a retainer excludes, in writing, before you sign. Because DeployOpen does not issue audit reports or certifications, the documentation supports your own assessments rather than replacing them.
