Analytics

2. The six criteria, in order, first match wins

2.1 Eliminators

Section 1. Whatever survives is the candidate set.

2.2 Operational model

2.3 User preference

preferences.json → design_constraints overrides 2.2. A customer consolidating onto AWS-native services has chosen EMR and OpenSearch; a customer with a Databricks contract has chosen Databricks on AWS. Either answer wins over the derived one.

2.4 Feature parity

Azure AI Search → OpenSearch. What carries and what does not:

The honest summary for the report: the index maps; the pipeline that fills it does not. An estimate that prices only the OpenSearch domain has priced the smaller half of the work for any search service that uses indexers or skillsets. Emit one warnings[] entry naming each indexer or skillset found.

When the search service exists only for RAG — vector fields, no faceting, no application-facing keyword search — say so, and name OpenSearch Serverless with Bedrock Knowledge Bases as the alternative worth evaluating. Do not silently substitute it: it changes the retrieval contract, so it is a recommendation for the report, not a mapping.

2.5 Cluster context

• A search service in a cluster whose compute is Lambda and whose data store is DynamoDB is a serverless estate; OpenSearch Serverless fits the operational posture even where a provisioned domain would be cheaper at steady state.
• A Databricks workspace in the same cluster as Synapse or Data Factory means the cluster is a data-pipeline pattern and defers at cluster level (§ 7a.8). The cluster-level gate wins: do not emit a per-resource Databricks mapping inside a deferred cluster.

2.6 Simplicity

Where both stand, prefer the target that keeps the customer’s existing operational model. Moving Databricks-on-Azure to Databricks-on-AWS changes one variable; moving it to EMR changes the platform, the job definitions and the team’s tooling at the same time as the cloud.

3. Databricks: the like-for-like is the default, and EMR is an optimization

Microsoft.Databricks/workspaces is the only row in this skill where the recommended target is the same third-party product on AWS. That is not a cop-out:

• Databricks on AWS is a first-party AWS Marketplace product with the same workspace, notebooks, job definitions and Unity Catalog. Migration is a workspace migration.
• EMR runs Spark. Every Databricks abstraction above Spark — Delta Live Tables, Workflows, SQL warehouses, Photon — has to be rebuilt on something else.

So the rule is: default to Databricks on AWS. Route to EMR only when § 2.4 confirms the workspace is plain Spark, and state in the rationale which Databricks features were checked for and not found. “EMR, because no Unity Catalog, Delta Live Tables or SQL warehouse usage appears in the workspace configuration” is auditable. “EMR is the AWS-native choice” is a preference dressed as a finding.

sku is a signal, not a size. premium buys Unity Catalog, role-based access and audit logging — read it as evidence Databricks-specific features are likely in use, which pushes toward Databricks on AWS. Do not translate the SKU into an instance type; the workspace has no compute of its own, its clusters do, and those are not in the IaC.

4. Sizing is post-selection

As in every rubric, the six criteria pick a service and never touch capacity.

• OpenSearch: replica_count × partition_count from the source is the starting point for data node count and shard count, not the answer. Azure AI Search’s replica/partition units are a pricing construct with fixed storage per partition; OpenSearch nodes are instances. Without utilization data, state a dev-tier default and say the sizing table is absent rather than inventing a node count.
• Databricks / EMR: the workspace declares no compute, so there is nothing to size from the inventory. Any cluster sizing is a Clarify or workshop input, and its absence is a stated assumption, not a gap to paper over.

knowledge/design/*.json carries no analytics sizing table, and unlike compute and database that is still true after 2026-09-07. So every OpenSearch node count and every Databricks or EMR cluster size from this rubric is stamped sizing_provenance: "model_prior" with a warnings[] entry, not table.

Per § 14 a missing sizing table degrades a number’s precision and does not halt, unlike a missing rubric file which fabricates the answer. That distinction holds — but “degrades precision” understates it when there is no table at all, which is exactly why the provenance field is required rather than optional.

5. Output

Per schema-design-aws.md § services[]: aws_service, aws_config (engine version, node type and count or serverless collection type, vector configuration), confidence: "inferred", rubric_applied: "analytics.md", and a rationale naming which criterion fired.

Every indexer, skillset and Databricks-proprietary feature found gets its own warnings[] entry. They are the part of the migration the mapping does not represent.

Status — build step 5b

Implemented for AI Search and Databricks — the two analytics types that route here. Synapse, Data Factory, Stream Analytics and Machine Learning workspaces are specialist gates by design and are not covered here. HDInsight and Data Explorer (Kusto) have no canonicalization row yet, so they reach the untranslated-type STOP rather than this file.