> ## Documentation Index
> Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migration guide

> Step-by-step migration guidance for upgrading Atoti Limits, covering property changes, dependency updates, data model changes, and configuration updates required for each version

# 4.2.2 to 6.1.20

<Warning>
  From version 6.1.20 onwards, Atoti Limits version numbers are aligned with the Atoti Java SDK. Previously, Atoti Limits used its own versioning (the last release under the old scheme was 4.2.2).

  The jump in version numbers reflects this alignment. There are no missing releases between 4.2.2 and 6.1.20.
</Warning>

Maven dependencies have changed: update the following group IDs in your `pom.xml`:

* `com.activeviam.solutions` → `com.activeviam.modules`
* `com.activeviam.solutions.limits` → `com.activeviam.modules.limits`
* `com.activeviam.solutions.services` → `com.activeviam.modules.services`

# 6.1.21 to 6.1.22

This release only shipped bug fixes and performance improvements. It does not require any migration.

# 6.1.20 to 6.1.21

This release only shipped bug fixes and performance improvements. It does not require any migration.

# 4.2.1 to 4.2.2

#### Scheduled evaluation properties

The properties used to configure the scheduled INTRADAY limit evaluation have been replaced. The old
properties are deprecated and will be removed in a future release, but still function as a fallback
if the new properties are not set.

<Note>
  You do not have to migrate these properties now, but we recommend doing so to reduce future upgrade efforts.
</Note>

| Old Property (deprecated)                | New Property                                   |
| :--------------------------------------- | :--------------------------------------------- |
| `limits.alert-task.sample-rate-cron`     | `limits.evaluation.scheduler.cron-expression`  |
| `limits.task-scheduler.thread-pool-size` | `limits.evaluation.scheduler.thread-pool-size` |

To migrate, replace the old properties in your `application.yml`:

```yaml theme={"languages":{"custom":["/engine/python-sdk/0.9/languages/pycon.tmLanguage.json"]}}
# Before (deprecated)
limits:
  alert-task:
    sample-rate-cron: 0 */5 * * * *
  task-scheduler:
    thread-pool-size: 4

# After
limits:
  evaluation:
    scheduler:
      cron-expression: 0 */5 * * * *
      thread-pool-size: 4
```

If both old and new properties are set, the new property (`limits.evaluation.scheduler.*`) takes
precedence.

#### Limit repository change

The Atoti Limits codebase now lives within the Atoti Server codebase, which streamlines dependency management. This means that the Atoti Limits pom now inherits from

```xml theme={"languages":{"custom":["/engine/python-sdk/0.9/languages/pycon.tmLanguage.json"]}}
<parent>
    <groupId>com.activeviam.modules</groupId>
    <artifactId>workflows</artifactId>
</parent>
```

where the version is aligned with the version of Atoti Server used by Atoti Limits, which for this release is `6.1.19`.

**Please update your pom parent to this artifact.**

The pom file no longer requires the `common-parent-pom`, `common-dependencies-bom` or `common-spring-services-bom`, so you can remove these.

# 4.2.0 to 4.2.1

#### Connected server configuration

##### Server name property for connected servers with default catalog name

Previously, if-and-only-if the `limits.autoconfiguration.server-name` property was not defined and
the connected Atoti Server used the default catalog name (`Catalog`), Atoti Limits would use
this default catalog name as the primary way to identify the connected server. This usually led to
issues when connecting to Atoti Limits and creating limits.

Now, if the connected Atoti Server uses the default catalog name (`Catalog`) then you must define the
`limits.autoconfiguration.server-name` property, or else the connection will fail with an exception.

To resolve this, set the `limits.autoconfiguration.server-name` property in your connected Atoti
Server’s configuration file (e.g. `application.yml`):

```yaml theme={"languages":{"custom":["/engine/python-sdk/0.9/languages/pycon.tmLanguage.json"]}}
limits:
  autoconfiguration:
    server-name: <your-server-name>
```

This will be used when creating limit structures to verify that the server for your structure is a
valid, connected server.

For more information on the available properties, see
the [limits integration common properties](../user-ref/properties/config-properties/limits-integration-common).

# 4.1.1 to 4.2.0

This guide explains how to migrate Atoti Limits from versions 4.1.1 to 4.2.0. This migration guide focuses on breaking changes. Consult the Atoti Limits 4.2.0 [release notes](./release-notes) and [changelog](./changelog) for a complete view of changes.

## What is the recommended migration process?

1. Back up your project.
2. Automatically migrate your code and/or data using
   the [Atoti Limits migration tool](#how-do-i-use-the-atoti-limits-migration-tool).
3. Perform a diff between older Atoti Limits release builds and newer release builds.
   * Update your dependencies.
   * Update your code.
4. Confirm successful build and startup.

### How do I use the Atoti Limits migration tool?

<Note>
  The migration tool doesn’t account for customizations nor does it account for all required changes.
  It is used as a helper to automate part of the migration process.
</Note>

The Atoti Limits migration tool is shipped with the Atoti Limits distribution files in
the `limits-migrations` folder. It is a script written in Java that automates part of the migration process
by updating your code and/or data to be compatible with the latest version of Atoti Limits.

#### How does the Atoti Limits migration tool work?

In general, the tool is installed and run as follows:

1. `cd limits-migrations`
2. Run `mvn clean install`
3. Run `java -jar path/to/limits-migrator-tool-exec.jar <target-version> <other-args>`

Replace `<target-version>` with the version you are migrating to (e.g. `4.2.0`),
and `<other-args>` with the version specific arguments accepted by the migration tool for the target
version. See the following section for more details.

#### 4.2.0 migration script

This migration script updates the following files from Atoti Limits 4.1.x to 4.2.x:

* `limit_structures*.csv`: Adds new columns `Limit Workflow Variables` and `Incident Workflow Variables`.
* `limits_approve*.csv`: Renames the `LimitValues` column to `Limit Value`. Adds a new column `Limit Changes Workflow Variables`.
* `incident*.csv`: Adds a new column `Limit Type`.

The original files are backed up in a separate folder, which you can delete after completing your migration. All new columns will be initialized as empty.
This script expects the following program arguments (in this order):

1. The target version of Atoti Limits, which should be `4.2.0`
2. The glob pattern of the structure files to be migrated, for example `*.csv` or
   `**/*structures*.csv`.
3. The glob pattern of the limit files to be migrated, for example `*.csv` or
   `**/*limits_approve*.csv`.
4. The glob pattern of the incident files to be migrated, for example `*.csv`, `**/*incidents*.csv`
   or `**/2025-12-09/incidents/*.csv`.
5. The root folder of the files, for example `./data` or `/path/to/data`.

## What dependencies have changed?

The following dependency changes are required for migrating Atoti Limits 4.1.1 to Atoti Limits 4.2.0.

#### Updated

<table><thead><tr><th>Dependency</th><th>Atoti Limits 4.1.1</th><th>Atoti Limits 4.2.0</th></tr></thead><tbody><tr><td>workflow-service</td><td>-</td><td><code>2.0.0</code></td></tr></tbody></table>

## How do I migrate my project?

The following information is applicable for migrating Atoti Limits 4.1.1 to Atoti Limits 4.2.0.

### Low-Code/No-Code

If you are using Atoti Limits 4.1.1 in a low code/no-code setup and migrating to Atoti Limits 4.2.0, you’ll need to know high-level changes. This section focuses on the high-level changes when migrating, such as configuration/property, data model, cube, and dashboard changes.

* [Loading data](#loading-data)
  * [Moving from the DLC to the new file loading service](#moving-from-the-dlc-to-the-new-file-loading-service)
  * [Additional fields for the structure csv file/database table](#additional-fields-for-the-structure-csv-filedatabase-table)
  * [Additional field for the limit csv file](#additional-field-for-the-limit-csv-file)
  * [Additional field for the incidents csv file/database table](#additional-field-for-the-incidents-csv-filedatabase-table)
* [Limit definition changes](#limit-definition-changes)
  * [Warning threshold behavior](#warning-threshold-behavior)

#### Loading data

##### Moving from the DLC to the new file loading service

In order to migrate your initial load configuration from the DLC to the new file loading service, you need to update the following properties in your `application.yml` file:

<table><thead><tr><th>Old (DLC) Property Name</th><th>New Property Name</th><th>Comment</th></tr></thead><tbody><tr><td>limits.dlc.root-dir</td><td>limits.initial-load.root-dir</td><td>The path to the directory containing the CSV files to load.</td></tr><tr><td>limits.dlc.path-matchers.limits</td><td>limits.initial-load.file-path-matchers.limits</td><td>The pattern to identify the CSV files containing limits.</td></tr><tr><td>limits.dlc.path-matchers.limitstructures</td><td>limits.initial-load.file-path-matchers.limit-structures</td><td>The pattern to identify the CSV files containing limit structures.</td></tr><tr><td>limits.dlc.path-matchers.incidents</td><td>limits.initial-load.file-path-matchers.incidents</td><td>The pattern to identify the CSV files containing incidents.</td></tr><tr><td>limits.dlc.path-matchers.asofdate</td><td>limits.initial-load.file-path-matchers.as-of-date</td><td>The pattern to identify the CSV files containing AsOfDates.</td></tr></tbody></table>

The following properties do not have an equivalent in the new configuration and can be safely
removed:

<table><thead><tr><th>Service/Configuration Class</th></tr></thead><tbody><tr><td><code>com.activeviam.limits.cache.cube.cfg.source.IDataLoadControllerConfig</code></td></tr><tr><td><code>com.activeviam.limits.cache.cube.cfg.source.ICSVSourceConfig</code></td></tr></tbody></table>

If you have customized the DLC configuration in Atoti Limits by overriding the default
implementations of these
configuration classes, you will need to replace your custom DLC beans with a custom implementation
of the
`ILimitsFileLoadingService` interface.
See [How to customize the file loading service](../dev/dev-extensions/custom-data-loading#how-to-customize-the-file-loading-service)
for more details on how to
override the default service.

Once you have created your custom `ILimitsFileLoadingService` implementation that mirrors the
behavior of your previous
DLC configuration, you can safely remove all DLC-related configurations from your project.

##### Date roll via file no longer supported

With the removal of the DLC, [rolling the date](../dev/date-roll) by sending the updated AsOfDate
file to the DLC
endpoint is no longer supported. Please use
the [Limits asOfDate endpoint](../dev/date-roll#trigger-a-date-roll-via-rest) to roll the date
instead.

##### Managing Workflows

If you have made customizations to the default workflows then you will need to update them to
conform to the new workflow service.