Migrating Sitecore XP 10.5 to Solr 10: Schema, Cores, Index Rebuilds, and Breaking Changes

The risky part of a search migration is the interval between “the server answers” and “the application still finds the right content.” A connection test can pass while a custom field is missing, a facet groups values differently, or a rebuild excludes documents supplied by an external crawler. Treat those as separate acceptance problems from the beginning.

For a Sitecore XP 10.4-to-10.5 project, prepare the Solr target as a prerequisite workstream. XP 10.5 requires Solr 10. The title describes the target integration; it should not be read as permission to operate XP 10.5 against an older Solr version while postponing search work. Verify the exact supported release through the Sitecore release resources and preserve that decision with the deployment record.

This article proposes an engineering procedure for custom cores, managed schema, field mappings, rebuilds, and acceptance. It does not report a migration executed against your installation. Commands use illustrative environment values and require your own endpoint, credentials, and approved test data. No rebuild duration, throughput, or performance improvement is claimed as a measured result.

My preference is to build and validate a separate target from authoritative sources before switching the application. That costs temporary capacity and requires a plan for changes during the build. I would still choose it over overwriting the only searchable copy without an independently tested recovery route. The important deliverable is a reproducible search contract, not a successful sequence of console clicks.

1. Inventory the search contract before provisioning

Map logical indexes to physical destinations

Create an inventory with one row for each logical index used by the solution. Record its application owner, physical core or collection, source of documents, schema provenance, update mechanism, and consumers. Include indexes used by authoring, delivery, and XP services where applicable. A custom index that appears only in a deployment script still belongs in the inventory if an application depends on it.

Separate the logical index identifier from the physical destination name. During a rehearsal, the logical application behavior should remain understandable even when physical names change to prevent collisions. Keep the relationship explicit in a mapping document. A reviewer should be able to start with a failing feature and identify the configured index, destination, document producer, and expected fields without reverse-engineering several repositories under incident pressure.

Identify every producer of documents. Standard content indexing may be only one source. A custom crawler could read a catalog, another system, or a generated dataset. Write down how that producer can replay its full corpus and what credentials it needs. If a source cannot be replayed, resolve that recovery problem before assuming that a rebuild is a reliable migration strategy for the index it feeds.

Define what search correctness means

Choose representative queries from actual application features. For each one, record the business intent, input, expected documents, relevant fields, ordering, and filtering behavior. Include the application identity or security context if it changes what should be visible. A query that returns plausible-looking content is not a useful acceptance test unless the team can explain what makes the result correct.

Use a test ledger that distinguishes exact equivalence from intentional change. An exact identifier lookup may require the same document. A relevance-ranked query may need a reviewed result set rather than an identical score. A facet may need agreed categories and counts for a controlled corpus. Ask the application owner to define the appropriate comparison before looking at the new results, so that acceptance is not rewritten to excuse whatever appears.

Preserve the old behavior with its context. Store the query parameters, content snapshot identifier, application build, and schema record together. If the content changes between comparisons, record that fact. Otherwise, a difference could come from migration behavior or simply from different data. A controlled sample is more useful than an enormous result dump whose provenance nobody can establish.

Inventory custom configuration as a dependency

List custom field maps, computed fields, query translators, schema populate helpers, analyzers, and provisioning scripts. Search the repositories and inspect the effective deployed configuration. Do not stop at the intended configuration files if the running environment has manual changes. Give every extension an owner and a target disposition: retain, adapt, remove, or investigate. An unexplained extension is an open migration item.

Capture the current schema and the source that is supposed to produce it. Those may differ. A manually patched core might contain a field that is absent from the deployment package; a package might contain definitions that were never applied. The migration should resolve that disagreement into one supported, repeatable process. Copying the unexplained result to the new server preserves the uncertainty rather than removing it.

Read the Apache upgrade notes for the actual versions crossed, including the packaged changelog. They are a separate input from Sitecore’s integration guidance. Pin the version reviewed in your release record: a URL containing latest can change after the project has selected its target. Do not import a command from a newer guide without checking it against the approved server package.

Choose a migration and recovery boundary

Decide which resources are preserved, which are rebuilt, and which can change during the operation. Include the source systems, update queues or schedules, application configuration, credentials, and old search destination. The inventory should explain how the application can return to a coherent previous state if the new search target is rejected. Merely retaining an old directory does not establish that it remains usable.

Estimate the work from a rehearsal using representative data and infrastructure. Measure preparation, schema deployment, ingestion, validation, and any catch-up period separately. Record the slowest required source and the test effort. This article supplies no expected rebuild time because your data volume, custom producers, hardware, and workload are not known. Use measured evidence to choose the production window and capacity.

The inventory phase is complete when every index has a source, owner, target mapping, replay method, and acceptance set. The release lead should be able to explain which features fail if one index is missing. That is a stronger readiness test than counting the number of configured cores and assuming the application uses all of them in the same way.

2. Provision Solr 10 and prove authenticated connectivity

Separate service readiness from client readiness

Provision the approved Solr release using the installation and hosting procedure selected for the project. Record runtime prerequisites, storage locations, service identity, network bindings, certificates, and configuration sources. This article does not provide a universal Java command or container image tag because those details must match the supported package and hosting model. Keep the exact procedure in the project’s infrastructure record.

Test the service from the network locations that will actually consume it. A successful local request on the search host does not establish that a delivery role, indexing worker, or isolated container can reach the same endpoint. Build a client-to-service matrix and test each required path. Record the destination, identity used, operation attempted, and outcome so that a failure can be localized later.

Keep initialization access distinct from normal runtime access where the approved deployment supports that separation. The operator creating resources may need operations that the application never uses. Design the role mapping with the service owner and verify permitted and rejected actions. Avoid solving a narrow authorization failure by leaving every application client on a broadly privileged account after migration.

Configure authentication and authorization deliberately

Apache’s security configuration guide separates authentication, authorization, and auditing, with configuration in security.json and location differences between SolrCloud and standalone installations. Follow the instructions for your mode. Do not treat a security file copied into an arbitrary directory as evidence that the running service is using it.

The Basic Authentication plugin documentation describes the authentication mechanism. Permission decisions remain an authorization concern. For the project, define a small operation matrix: who provisions resources, who populates schema, who indexes, who queries, and who operates monitoring. Then test those identities using the operations they actually need rather than inferring permission from a successful sign-in.

Keep secret values out of the article, repository examples, and public evidence. Use the project’s approved secret store and injection mechanism. Record secret references and rotation ownership in the deployment manifest. The operator needs to know which value belongs to which client without placing the value itself in a screenshot or release ticket. Review logs from failed requests for accidental credential disclosure before sharing them.

Use a read-only diagnostic before an indexing test

The following PowerShell example requests the schema from an illustrative HTTPS endpoint and prompts for a credential. It is a diagnostic pattern, not an instruction to create a production account or grant schema-edit access. Replace the endpoint and core with the approved test destination. The API route is documented in Apache’s Schema API reference. Keep the response in a protected evidence location if it exposes internal field names.

$searchCredential = Get-Credential
$schemaEndpoint = 'https://solr.example.internal:8983/solr/project_web_index/schema'
$schemaResponse = Invoke-RestMethod -Uri $schemaEndpoint -Method Get -Credential $searchCredential
$schemaResponse.schema.name

Run the diagnostic from a location representative of the intended client. Verify the server identity and certificate trust through the approved path. If a test works only after disabling certificate validation, record it as a failed trust configuration rather than a successful connection. The production acceptance should demonstrate the intended security controls, not a temporary bypass used to narrow a problem.

After read access passes, use a dedicated test resource and approved sample to verify the required write path. Separate this from production data and clean up through the documented procedure. A read-only query proves a different capability from schema management or indexing. Keep each outcome distinct in the matrix so that later troubleshooting can tell which path was actually exercised.

Make failures diagnosable without broadening access

When a request fails, preserve the destination, timestamp, client identity reference, response status, and relevant server event. Do not include the secret. Determine whether the failure occurred before the request reached the service, during authentication, during authorization, or in the requested operation. These are diagnostic categories, not a promise that every proxy or hosting layer will return the same error code.

Verify health and monitoring clients too. A protected service might require a probe identity or a documented endpoint appropriate for the hosting platform. Follow the deployment’s approved mechanism rather than making the entire service anonymous because a probe fails. Ask the operations owner to demonstrate that a real failure is detected and that the available evidence identifies the affected client path.

The connectivity gate passes when every required client reaches the intended destination with the intended trust and permission model. Preserve that matrix before moving on. If schema population later fails, you will have evidence to distinguish an operation-specific problem from a basic network or identity problem instead of repeating the same informal connection checks.

3. Migrate managed schema and field mappings

Keep the integration changes visible

The Sitecore-specific change register includes managed-schema.xml naming, removed version-specific populate helpers, SortableTextField-based mappings, POST query defaults, authenticated connections, and the UseEnumFacetMethod workaround for affected pivot facets. Custom helper and dependency-injection assumptions also need review. Use the exact affected members and settings in the official breaking-change reference as your remediation checklist, rather than treating this short register as a complete substitute.

For each applicable entry, link a repository location, planned change, and acceptance test. Mark entries that do not apply and explain why. This converts a long release document into an accountable worklist. It also stops an engineer from fixing a build error while overlooking the deployment script or runtime registration that supplies the same extension in another environment.

Do not copy the old schema wholesale as the target baseline. Start with the approved target resources and apply understood custom requirements. Preserve the old definition for comparison. The useful question for a field is what the application expects it to do, not whether a line from the old XML can be pasted into a file with the same general purpose.

Build a field-intent ledger

For each custom field, record its source value, emitted field name, expected cardinality, selected type, analysis behavior, retrieval needs, and query uses. Add separate notes for filtering, sorting, faceting, and full-text relevance where those uses exist. A single field may be asked to serve incompatible business expectations; the ledger exposes that design question before a rebuild makes it expensive to change.

Use concrete sample values. Include missing data, repeated values, punctuation, mixed case, accented characters, long values, and the languages the application supports. Those are proposed test categories to choose from, not a claim that every field requires every case. Explain which behavior the sample tests and what result the business owner expects. A representative example is better than an unreviewed collection of random strings.

Apache’s field-type reference describes the role of type properties and analysis. Use it to inspect the actual selected definitions rather than relying on a familiar type name. In the ledger, write down the intended behavior in plain language first. Then connect that intent to the configured property and the test that will demonstrate it.

Inspect managed schema through the supported mechanism

The schema factory documentation distinguishes managed schema from a manually maintained schema.xml and explains that managed schema does not automatically mean schemaless indexing. Confirm the factory and mutation approach used by your target. Do not mix manual file edits and API-driven changes without a deliberate procedure for which source is authoritative.

Capture the target schema before and after the approved populate operation. Compare fields, dynamic rules, types, and copy rules relevant to the application. The goal is to verify the effective result, not to assert that an operation completed because a UI displayed a success notification. Keep the comparison with the application artifact and configuration identifiers that produced it so the result can be reproduced.

A schema diff should be interpreted rather than blindly accepted. Group changes into target defaults, intended custom additions, expected removals, and unexplained differences. Ask an owner to resolve the last category. If a field appears only because of an ad hoc command, put its definition into the approved provisioning process or remove it through an approved redesign. Otherwise the next environment can diverge again.

Review the query-facing meaning of the change

Inspect fields used by customer-facing facets and ordering before accepting the schema. Choose examples where tokenized search behavior and displayed labels have different needs. If the application previously grouped tokens but now needs whole business values, document that distinction and select an appropriate design through the supported target guidance. Do not change a field merely to make a single test pass without checking its other consumers.

For language-specific fields, connect the source language, emitted field, configured analyzer, and expected query behavior in the same test record. If the application supports several locales, select samples that exercise the relevant analysis choices. A successful default-language query should not be generalized into a claim that every language path works. Record any untested path as a coverage limit for the reviewer.

The schema gate passes when custom fields have explained intent, the target definition is reproducible, and each material query-facing change has an acceptance test. Keep the initial target snapshot and the approved final snapshot. They make later diagnostics much faster than trying to reconstruct which environment-specific edit happened after the original populate operation.

A worked field-review exercise

Consider a proposed catalog field called product_family. The business owner wants visitors to filter by the complete family name, see a readable label, and sort results using an agreed ordering. An editor also wants the general search box to find words that appear in that name. These are example requirements, not a claim about an existing project or a recommendation to use one particular Solr type. Write the requirements separately before selecting the mapping.

Create a controlled sample with three records: one named “Outdoor Equipment,” one named “Indoor Equipment,” and one with no family value. Give each a stable test identifier. Ask the owner what a search for “Equipment” should return, what filter choices should appear, and where the missing value belongs in an ordered result. Record those answers. They are the acceptance contract; the selected field design must be tested against all of them.

Now inspect the producer. Identify the original source value, the emitted document field or fields, and any normalization performed before indexing. If the source contains a readable name but the producer emits an unrelated identifier, make that relationship explicit. If the application expects to display a name while filtering by an identifier, test both sides. A field name in the schema does not explain which value the application actually sends or receives.

Compare the current and proposed target definitions using that sample. Run the exact application feature for term search, filtering, and ordering. Preserve the requests and expected identifiers. If one design meets the term-search requirement but does not meet the reviewed filter behavior, treat that as a field-design decision rather than a reason to relax the test. The remedy could involve a different mapping or separate representations, but choose it through the supported configuration and the application’s reviewed requirements.

Repeat the exercise for a language-specific value only if the feature supports that language. Ask whether translated labels should form separate categories or map to a shared business identity. That decision belongs to the product and content model. Search configuration can implement the chosen rule, but it should not invent the rule during migration. Keep the decision in the field ledger so that adding another language later does not reopen an undocumented assumption.

Use the missing-value record to check the user interface as well as the search result. The interface might need an explicit uncategorized choice, a hidden empty label, or another approved behavior. Do not let an accidental empty facet label become the product decision. Record the chosen presentation and the data condition that triggers it, then include that test when the application mapping or response handling changes.

After the initial sample passes, change one record’s family value through the normal source update path. Verify the new term, the new filter membership, and the removal of the previous membership according to the application’s freshness rule. Then remove the controlled record through the approved test procedure and verify its disappearance where required. This sequence tests the lifecycle that a static rebuild sample misses.

The result of this exercise is a completed field ledger entry with business intent, source provenance, emitted representation, target definition, and repeatable acceptance cases. It does not establish that every field behaves correctly. Select additional examples according to the application’s actual risk: a high-traffic navigation facet, a custom computed value, a permission-sensitive result, or another feature whose failure would matter during cutover. Keep the selection reason with each case.

4. Adapt custom helpers and rebuild from the source

Treat compilation as one layer of evidence

Rebuild custom search projects against the selected target dependencies. For each changed helper, processor, or factory, inspect how the running application creates and configures it. A compiling class can still be absent from the effective pipeline or constructed with different dependencies. Link the code review to a runtime test that demonstrates the intended extension was invoked and produced the expected schema or document behavior.

Search for references to removed or changed extension points using the exact identifiers in the vendor change register. Keep a disposition for each match, including test projects and tooling that runs outside the normal application. The point is not to remove every matching string. It is to decide whether a reference is dead code, an unsupported assumption, or an extension that needs a supported replacement.

Avoid substituting a new type name mechanically without reviewing the extension’s purpose. If the custom helper existed only to compensate for a former baseline behavior, the target may need less customization. Conversely, an extension implementing a business-specific schema rule may still be required. Write the purpose in the review so that future engineers can tell why the customization survived the upgrade.

Rebuild according to a documented ingestion plan

Apache’s reindexing guidance explains that schema changes do not rewrite documents already indexed and recommends a repeatable reindexing process, including a new collection as one strategy. Use that principle with the Sitecore-supported rebuild mechanism for each logical index. Do not improvise destructive delete commands against the only live destination as a shortcut.

For the Sitecore portion, follow Update Solr schema and rebuild indexes and the applicable XP instructions. Keep content indexes and xDB-related indexing work distinct in the plan. A completed content index rebuild should not be treated as evidence that every XP consumer has its required searchable data.

Order the work according to application dependencies and available capacity. Record which sources can run together, which require exclusivity, and which have a replay window. These are project decisions to measure in rehearsal. Do not assume that parallelizing every producer will shorten the overall window; it could make the workload less predictable or obscure the source of a failed batch.

Account for changes made during the build

A separate target raises a practical question: what happens to source changes while it is being populated? Decide whether the project freezes writes, replays a documented change stream, performs a final catch-up, or uses another supported method. State the boundary and test it. A target built from yesterday’s snapshot is not current merely because the rebuild process ended successfully.

Use a controlled marker change to exercise the selected update path in rehearsal. Record the source identifier, change time, expected destination, and observation method. Verify a create, an update, and a removal where those behaviors matter. The marker is a proposed test artifact, not a claimed Sitecore diagnostic feature. Keep its lifecycle and cleanup under the application owner’s control.

Custom external sources need their own reconciliation. Identify records that disappeared from the source, records updated during a long ingest, and records that failed transformation. Decide how the producer reports and retries those conditions. A rebuild that logs errors and continues might still produce an apparently healthy but incomplete index, so acceptance needs a source-level account of unresolved failures.

Verify completion without relying on a single count

Record producer completion, failed batches, expected sample identifiers, and the timing of the last applied source change. A document count can help with a controlled comparison, but explain what is being counted and why equivalence is expected. Different exclusion rules or document models can make an equal count misleading. Do not accept a count as a substitute for verifying the content required by critical queries.

Preserve logs with correlation to the logical index and source. If the process must be retried, document whether the destination was reset and how duplicate or stale documents are prevented by the approved mechanism. Avoid treating a second successful run as proof that the first partial attempt left no unwanted state. Verify the resulting corpus through the same acceptance process used for a clean build.

The rebuild gate passes when each source has completed through a repeatable producer, unresolved errors have dispositions, and the target’s freshness boundary is known. Keep the previous target or other recovery resources according to the approved plan. Only the next phase can establish whether the new corpus satisfies the application’s search contract.

5. Validate queries, facets, sorting, and updates

Use a result comparison that answers a business question

Run the accepted query ledger through the application path and, where useful, inspect the corresponding search request through approved diagnostics. Record the deployed build, logical index, physical destination, test identity, and data snapshot. If the direct request and application result differ, retain both. The discrepancy can help locate a mapping or application-layer issue without assuming that every problem belongs to the search server.

Use a compact record such as the following proposed JSON structure. The identifiers and expected results are placeholders to replace with a controlled sample. It is intentionally a test specification rather than an API response. Keeping expected behavior outside an ad hoc manual request makes it easier to rerun the same comparison after a schema or code correction.

{
  "case": "catalog-category-filter",
  "applicationBuild": "record-tested-artifact",
  "logicalIndex": "project_web_index",
  "dataset": "approved-rehearsal-snapshot",
  "input": { "term": "sample", "category": "controlled-category" },
  "expectedIds": ["controlled-record-a", "controlled-record-b"],
  "expectedFacetLabels": ["reviewed-label"],
  "securityContext": "approved-test-user",
  "result": "not-executed"
}

For exact-match tests, compare the relevant identifiers and fields. For relevance tests, have an application or content owner review the selected results and record the acceptance rule. Avoid comparing opaque score values as if their equality were the business objective. The question is whether the query still satisfies the feature’s contract under the target configuration, including intentional behavior changes approved before cutover.

Test facets as a separate feature

Apache’s faceting reference explains field and pivot facet concepts and parameters. Use it to identify what the application actually sends. A page described as “faceted search” could depend on several distinct requests or combinations. Capture the parameters and expected labels for each material path rather than testing one visible filter and assuming the rest are equivalent.

Use a small, controlled corpus to reason about expected facet labels and counts. Include records that exercise the selected category structure and records excluded by a filter or security context. Write down why a label should appear and which documents contribute to it. This makes an unexpected result actionable: the reviewer can trace it to a field value, query condition, or schema choice.

If a documented workaround is relevant, apply it in the rehearsal configuration and repeat both the affected test and nearby unaffected tests. Record why the workaround is needed and where the setting is supplied. Do not leave an unexplained global switch in the solution merely because it made one screen look correct. Keep its performance implications in the workload comparison instead of assuming it is cost-free.

Verify ordering and edge cases

For sorting, select values that expose the business ordering rule. Include missing values and equal values where the application supports them, and decide how the result should behave. If pagination matters, test the transition between pages with a controlled dataset. The test should establish a predictable user experience, not only the presence of a sort parameter in a request.

Review display values separately from search tokens. A label shown in the interface may have different requirements from the value used for matching. If a field serves both purposes, test both explicitly. Ask the application owner whether an intentional normalization belongs in ingestion, field design, or presentation. Avoid an unreviewed transformation that repairs one query while changing the meaning of a displayed category.

Use language, punctuation, long values, and repeated values only where they reflect the supported feature. Keep the sample set purposeful. A test suite full of arbitrary edge cases can be expensive to interpret and still miss a critical business rule. Link each test to the field-intent ledger so that someone changing a mapping can identify which acceptance cases need to run again.

Test updates after the initial rebuild

Verify a representative source change through its normal update path after the initial corpus is accepted. Record how the team observes the change reaching the search destination and when it becomes visible to the application. Use the application’s agreed freshness requirement. This article does not invent a fixed latency target or claim that a particular deployment meets one.

Repeat a relevant search after a controlled deletion or unpublish operation where the feature requires that behavior. A migration can appear successful on a static snapshot while the ongoing update process is misconfigured. Retain the evidence connecting the source action, indexing activity, and final application result. That record is useful both for acceptance and for future incident diagnosis.

The query gate passes when the chosen ledger has reviewed outcomes, intentional differences are accepted, and the ongoing update path has been demonstrated. Preserve failed cases and their resolutions too. They explain why a field or setting changed and reduce the chance that a later cleanup removes a necessary migration adaptation.

6. Diagnose failures and switch the application safely

Use a diagnostic ladder

Start with the failed business action and identify the first layer with missing or contradictory evidence. Is the application pointing at the intended logical index? Does that mapping reach the intended physical destination? Did the service receive the request? Was the intended identity accepted? Does the effective schema contain the expected field? Does the corpus contain the expected document? Is the application interpreting the response correctly?

Change one relevant variable at a time in the controlled environment and retain the before-and-after evidence. If credentials, schema, query code, and corpus are changed together, a successful retry does not explain the cause. That uncertainty can return during production. A diagnostic record should identify the hypothesis, intervention, observed result, and reason the team believes the cause has been resolved.

The following table is a proposed triage aid. It does not promise a universal error code or root cause. Use it to decide which evidence to collect next, then verify the actual failure against the relevant product guidance and environment configuration. A supplier incident should include a minimal reproduction and sanitized logs rather than a conclusion unsupported by the available observations.

Prepare the switch as a release operation

Choose the supported switching mechanism for your topology and Sitecore integration. A SolrCloud alias, a core strategy, and an application endpoint change are not interchangeable procedures. Record the exact resource mapping and the command or deployment action approved for the project. Rehearse it with the same logical identifiers that the application uses so the test exercises the real resolution path.

Before the switch, confirm target freshness, query acceptance, monitoring, and recovery readiness. Identify which writers must pause or catch up and who verifies that boundary. Preserve the source and target mappings in the release record. If the target’s data is already behind the agreed boundary, switching to it because all infrastructure checks are green does not satisfy the application’s acceptance contract.

After the switch, verify the destination actually serving the application and run the selected critical queries. Check a known document, a material filter, and the update path chosen for the production smoke test. Use safe data and the approved observation method. Keep broader testing in rehearsal, but do not skip the production confirmation that the intended mapping and credentials reached the intended roles.

Know what a return switch can recover

Retaining a previous index is useful only if the application release and source state remain compatible with it. Record what happened to updates during the migration and whether the old destination remained current. If it did not, the return procedure needs an explicit freshness and reconciliation decision. Do not equate changing a connection string back with restoring an entire application estate.

Define rollback triggers and a decision owner before production. A trigger might be an accepted critical query failing, an unresolved authorization boundary, or target freshness outside the locally agreed requirement. The exact thresholds belong to the application and operations owners. Use rehearsal timings to reserve a recovery window instead of attempting fixes until no return option remains.

Preserve diagnostic evidence before returning service to the previous target. Record the failing query, relevant data sample, application artifact, effective schema identifier, and operation logs. That package should let the team reproduce the failure later without leaving the broken target in the production path. Protect sensitive request content and credentials using the same evidence controls applied during testing.

Hand over a reproducible search service

Document how the accepted target is provisioned, how schema is populated, how every source is replayed, and how query correctness is checked. Assign ownership for secrets, certificates, capacity, monitoring, and custom producers. A future operator should be able to distinguish a source-data issue from a query or infrastructure issue using the same ledger and diagnostic ladder established during migration.

Retire old resources only after the agreed observation period and recovery decision. Confirm which backups or configuration records remain and who owns them. Keep a record of intentional behavior changes so that a later support ticket about a different facet label is not misdiagnosed as an unexplained regression. Link the change to the acceptance decision and the test that demonstrates the intended result.

The next concrete task is to populate the logical-to-physical index map and select a controlled query ledger for your solution. With those artifacts, the team can prove connectivity, inspect schema, rebuild reproducibly, and judge results against an agreed contract. Without them, a search migration remains a sequence of plausible actions with no reliable way to tell whether the application still finds what its users need.