> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/zingg/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/zingg/running-zingg/reassign-zingg-id.md).

# Reassign Zingg ID

Preserve Zingg IDs when switching to a new trained model or migrating infrastructure without disrupting downstream systems.

{% hint style="info" icon="right-long" %}
Enterprise Plus only. Preserves Zingg IDs when switching to a new model. Maximises ID continuity and minimises downstream disruption. Available in ZinggES (Enterprise Plus).
{% endhint %}

When you evolve your Zingg setup — upgrading your model, migrating infrastructure, changing data schemas, or moving to a new platform — you want to preserve the Zingg IDs already flowing through your production systems.

The `reassignZinggId` phase carries Zingg IDs from your original production model to a new model's output. It maps clusters from the new model back to the original cluster assignments and preserves the original Zingg IDs wherever clusters overlap. New IDs are generated only where no match is found.

{% hint style="info" icon="right-long" %}
For what the Zingg ID is and how it works in Enterprise output → [Zingg ID and Z Cluster](/zingg/zingg-concepts/z-cluster-and-zingg-id.md)
{% endhint %}

### When to use Reassign Zingg ID

<details>

<summary><strong>Model upgrades</strong></summary>

When you add new features like nickname support, improve blocking strategies, or tune classifiers, the new model may produce different clusters than the original. Use `reassignZinggId` to carry over original IDs to the new model output wherever clusters overlap, so downstream systems are not disrupted.

</details>

<details>

<summary><strong>Infrastructure migration</strong></summary>

Are you moving from Spark to Snowflake or from Databricks to Microsoft Fabric?\
Use `reassignZinggId` to maintain the same Zingg IDs across platforms when the underlying data and model are otherwise equivalent.

</details>

<details>

<summary><strong>Schema changes</strong></summary>

If your data schema changes, new fields are added, fields are removed, or field types are updated. Use reassignZinggId to preserve IDs for records that can still be matched via primary key to the original output.

</details>

<details>

<summary><strong>Data migration</strong></summary>

When migrating data between systems or consolidating data sources, `reassignZinggId` maintains ID consistency across the migration. Downstream systems that reference Zingg IDs continue to work without any updates.

</details>

### How it works

The reassign phase compares two configurations:

* **Original configuration**: your production model with established Zingg IDs.
* **New configuration**: your updated model with improved features, new infrastructure, or schema changes.

The reassign phase then:

1. Identifies clusters in the new output that overlap with original clusters via primary key matching
2. Reassigns the original Zingg IDs to matching clusters wherever possible
3. Generates new Zingg IDs only when no match is found in the original clusters

### Worked example

**Original model (production):** 4 records in a cluster, Zingg ID = `ZID-7f3a`. Records: A, B, C, D.

**New model (upgraded):** 6 records in the equivalent cluster. Records: A, B, C, D, E, F (E and F are new records added since the last full match).

**After `reassignZinggId`:**

* Records A, B, C, D → `ZID-7f3a` (Zingg ID from the original output preserved via primary key overlap)
* Records E, F → `ZID-9b2c` (new Zingg IDs generated for records with no match in the original)

Downstream systems that reference `ZID-7f3a` continue to work without any change.

{% tabs %}
{% tab title="Enterprise Python" %}

### **Step 1: Define the original (baseline) configuration**

Set up `EArguments` matching your existing production model. This is the model whose Zingg IDs you want to preserve.

```python
from zingg.client import*
from zingg.pipes import*
from zinggEC.enterprise.common.EArguments import*
from zinggEC.enterprise.common.EFieldDefinition import EFieldDefinition
from zinggES.enterprise.spark.ESparkClient import*
from zinggEC.enterprise.common.CompareArguments import*
from zinggEC.enterprise.common.EClientOptions import*

originalArgs = EArguments()
#... your original field definitions...
originalArgs.setModelId("107")
originalArgs.setZinggDir("./models")
originalArgs.setNumPartitions(4)

schema = (
    "id string, fname string, "
    "lname string, stNo string, "
    "add1 string, city string, "
    "areacode string, state string, "
    "dob string, ssn string"
)

originalInputPipe = ECsvPipe(
    "originalData",
    "examples/febrl/test.csv",
    schema
)
originalArgs.setData(originalInputPipe)

originalOutputPipe = ECsvPipe("originalOutput", "/tmp/zinggOutputOriginal")
originalOutputPipe.setHeader("true")
originalArgs.setOutput(originalOutputPipe)
```

Add all field definitions from your original production config - only a few are shown above as a pattern.

### **Step 2: Define the new (updated) configuration**

Set up `EArguments` for your new model. This is the model that produced the new cluster assignments which need Zingg IDs reassigned.

```python
newArgs = EArguments()
#... your updated field definitions...
newArgs.setModelId("999")
newArgs.setZinggDir("./models")
```

Add all field definitions from your new model config - only the structure is shown above.

### **Step 3: Run `trainMatch` on the new configuration first**

The new model must produce its own match output before reassign can compare clusters.

```python
options = EClientOptions([EClientOptions.PHASE, "trainMatch"])
zinggNew = EZingg(newArgs, options)
zinggNew.initAndExecute()
```

### **Step 4: Create `CompareArguments`**

`CompareArguments` wraps both configurations and the destination for the reassigned output.

```python
reassignArgs = CompareArguments()
reassignArgs.setParentArgs(newArgs)
reassignArgs.setOriginalArgs(originalArgs)

reassignOutputPipe = ECsvPipe("reassignedOutput", "/tmp/zinggReassigned")
reassignOutputPipe.setHeader("true")
reassignArgs.setResults(reassignOutputPipe)
```

### Step 5: Execute `reassignZinggId`

```python
reassignOptions = EClientOptions([EClientOptions.PHASE, "reassignZinggId"])
zinggReassign = EZingg(reassignArgs, reassignOptions)
zinggReassign.initAndExecute()
```

{% endtab %}

{% tab title="Enterprise JSON" %}

### **Configuration wrapper (`reassignConf.json`)**

The JSON wrapper config references your new model config and specifies the destination for the reassigned output.

```json
{
  "config": "$ZINGG_ENT_REPO$/spark/examples/febrl5M/configUpdated.json",
  "transformedOutputPath": {
    "name": "reassignedOutput",
    "format": "csv",
    "props": {
      "location": "/tmp/zinggTransformedOutputReassigned5M",
      "delimiter": ",",
      "header": true
    }
  }
}
```

* `--conf` - the wrapper config (`reassignConf.json`) that references your new model
* `--originalZinggId` - your original production configuration
* `--properties-file` - optional Zingg properties file

The CLI command takes three arguments:

```bash
./scripts/zingg.sh \
  --phase reassignZinggId \
  --conf <location to reassignConf.json> \
  --originalZinggId examples/febrl5M/config.json \
  --properties-file config/zingg.conf
```

{% endtab %}

{% tab title="Enterprise Snowflake" %}

### **Configuration wrapper (`reassignConf.json`)**

The JSON wrapper config references your new model config and specifies the destination for the reassigned output.

```json
{
  "config": "configUpdated.json",
  "transformedOutputPath": {
    "name": "reassignedOutput",
    "format":"snowflake",
    "props": {
      "table": "OUTPUT_REASSIGN_Febrl_5M"
    }
  }
}
```

* `--conf` - the wrapper config (`reassignConf.json`) that references your new model
* `--originalZinggId` - your original production configuration
* `--properties-file` - optional Zingg properties file

The CLI command takes three arguments:

```bash
./scripts/zingg.sh \
  --phase reassignZinggId \
  --conf <location to reassignConf.json> \
  --originalZinggId examples/febrl5M/config.json \
  --properties-file ./snowflakeConn.properties
```

{% endtab %}
{% endtabs %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zingg.ai/zingg/running-zingg/reassign-zingg-id.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.