Pular para o conteúdo principal

Rolling back a Signer version

This article describes how to roll an on-premises 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) using the package of the previous version.

2. Check whether the update changed the database​

Check the 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.

4. Configure the database connection​

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

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

5. Identify the applied migrations​

Connect to the database and run:

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, 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:

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

Example:

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

7. Validate the rollback​

Run the query from step 5 again:

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​

View as Markdown