---
title: "Rolling back a Signer version"
description: "How to roll an on-premises Signer back to a previous version: restore the binaries and, if the update applied migrations, revert the SQL Server database with the update-db command."
canonical: "https://docs.lacunasoftware.com/en-us/articles/signer/on-premises/rollback"
locale: "en"
product: "Signer"
last_updated: "2026-10-20"
---

# Rolling back a Signer version

This article describes how to roll an [on-premises](https://docs.lacunasoftware.com/en-us/articles/signer/on-premises) [Signer](https://docs.lacunasoftware.com/en-us/articles/signer) instance back to a previous version, including reverting the database changes (*migrations*) applied by the update.

> **Warning**
>
> This is a sensitive, **high-risk** procedure. A rollback may cause **severe, irreversible data loss**. Perform it only when absolutely necessary.
>
> Whenever possible, report the bug or problem to the Lacuna Software team instead of rolling back.
>
> The decision to roll back or not, and its consequences, are **solely the responsibility of the team that manages the instance**.

## Before you start

You will need:

* access to the application servers;
* access to the database (SQL Server);
* .NET installed in the environment where the command will run;
* the database connection string.

We strongly recommend that you:

* **back up the database** before you start;
* test the procedure in a staging environment first.

> **Danger**
>
> Rolling back migrations cannot be undone automatically and, depending on the migrations removed, may cause data loss. If you have any doubt about which migrations must be removed, **do not proceed** and contact the Lacuna Software team.

## Step by step

### 1. Stop the application and revert the binaries

1. Stop all Signer application servers.
2. Revert the binaries to the previous version, the one you want to return to. To do so, follow the update instructions for your platform (for example, [Linux](https://docs.lacunasoftware.com/en-us/articles/signer/on-premises/linux/update)) using the package of the previous version.

### 2. Check whether the update changed the database

Check the [Signer changelog](https://docs.lacunasoftware.com/en-us/articles/signer/changelog) to see whether the version currently in use changed the database model. These changes appear in the changelog as *Updates database model* and are applied by migrations. Also confirm that the migrations were actually applied to your database (step 5).

* If **no migrations were applied**, just revert the binaries (step 1) and start the application (step 8). You do **not** need to run steps 3 to 7.
* If **migrations were applied**, they must be removed. Follow the next steps.

### 3. Get the binaries of the version that was applied

> **Important**
>
> Use the binaries of the version currently in use (the one you want to roll back), **not** those of the previous version. They are the ones that contain the migrations to be removed.

Download the package of the applied version and extract it to a working directory:

* Windows: `.zip` package
* Linux: `.tar.gz` package

The download links for each version are in the [Signer changelog](https://docs.lacunasoftware.com/en-us/articles/signer/changelog).

### 4. Configure the database connection

In the `appsettings.json` file of the working directory, add the connection string:

```json
"ConnectionStrings": {
  "DefaultConnection": "<connection string>"
}
```

### 5. Identify the applied migrations

Connect to the database and run:

```sql
select * from __EFMigrationsHistory order by MigrationId
```

This table lists all applied migrations. The `MigrationId` field has the format `YYYYMMDDHHMMSS_MigrationName`.

Then:

1. Compare the list with the [changelog](https://docs.lacunasoftware.com/en-us/articles/signer/changelog), which lists the migration names of each version.
2. Identify which migrations belong to the version you want to roll back.
3. Determine the **last migration that must be kept**. This is the *target migration*.

### 6. Roll back the migrations

To remove all migrations after the target migration, run the following in the working directory:

```sh
dotnet Lacuna.Signer.Site.dll -- update-db <target migration name> --timeout 6000
```

Example:

```sh
dotnet Lacuna.Signer.Site.dll -- update-db 20250101120000_SomeMigration --timeout 6000
```

### 7. Validate the rollback

Run the query from step 5 again:

```sql
select * from __EFMigrationsHistory order by MigrationId
```

Check that:

* the last migration in the list is the target migration;
* the later migrations were removed.

### 8. Start the application

Start the Signer application servers again.

## Summary

1. Stop the servers and revert the binaries to the previous version.
2. Check the changelog and confirm whether migrations were applied.
3. Download the binaries of the version that was applied.
4. Set the connection string in `appsettings.json`.
5. Identify the target migration in `__EFMigrationsHistory`.
6. Run `update-db <target migration>`.
7. Validate the `__EFMigrationsHistory` table.
8. Start the application.

## See also

* [Signer changelog](https://docs.lacunasoftware.com/en-us/articles/signer/changelog)
* [Updating to 3.x](https://docs.lacunasoftware.com/en-us/articles/signer/on-premises/update-30)
* [Updating Signer on Linux](https://docs.lacunasoftware.com/en-us/articles/signer/on-premises/linux/update)