Upgrade Guide

This guide covers how to upgrade the Function Apps, frontend SPA, and database schema in a self-hosted enterprise Veriproof deployment.

Enterprise deployment packages are delivered as versioned releases. Contact your Veriproof account manager or check your enterprise package repository for new versions.

Upgrade Principles

Schema migrations are always additive in minor and patch releases — no existing columns or tables are removed. Breaking schema changes only occur in major version upgrades, with a migration guide.
Function App and SPA releases are independent — you can update the backend Function Apps without immediately updating the frontend, or vice versa. The API is backward compatible within a major version.
Database migrations are idempotent — you can re-run migration scripts if a previous run was interrupted.
Always back up before upgrading — take a PostgreSQL snapshot before applying schema migrations.

Standard Upgrade Procedure

Review the release notes

Check the release notes for the new version. Look for:

Breaking changes (rare, only in major versions)
Required configuration changes
New environment variables
Schema migration requirements

Back up the database


pg_dump \
  "postgresql://admin:<password>@your-server.postgres.database.azure.com/veriproof" \
  -F c -f "backup-$(date +%Y%m%d-%H%M%S).dump"

Or trigger an on-demand backup via the Azure Portal.

Apply schema migrations

Run new migration scripts against your database. Migrations are found in the migrations/ directory of the enterprise package:


psql "postgresql://veriproof_admin:<password>@your-server.postgres.database.azure.com/veriproof" \
  -f migrations/003_new_feature.sql

All migrations are idempotent — safe to re-run.

Update Function App environment settings

If the release notes specify new application settings, add them to both Function Apps before deploying the new code:


az functionapp config appsettings set \
  --name your-customer-api-app \
  --resource-group your-rg \
  --settings NEW_SETTING="value"

Deploy new Function App code


# Customer Portal API
func azure functionapp publish your-customer-api-app --configuration Release
 
# Ingest API  
func azure functionapp publish your-ingest-api-app --configuration Release

Deploy updated frontend

Rebuild the SPA with the new version and redeploy to Azure Static Web Apps:


cd portal-frontend
npm ci
npm run build
az staticwebapp deploy --name your-portal-swa --source ./dist

Validate

Navigate to the portal and confirm the version number shown matches the new release
Verify GET /v1/system/health returns 200
Verify GET /v1/deployment/context returns the correct deployment mode and setup state
Run a test ingest to confirm commitment submission is working

Rolling Back

If an upgrade causes issues:

Redeploy the previous Function App version (kept as a deployment slot or artifact in your CI/CD store)
The database schema is backward compatible — no rollback migration is needed for minor/patch upgrades
Redeploy the previous SPA version

For major version rollbacks involving schema changes, execute the rollback SQL scripts provided in the enterprise package.

Version Compatibility

Component	Compatibility rule
Function App ↔ Database	Minor/patch: backward compatible. Major: run migration scripts.
SPA ↔ Function App API	SPA works with Function Apps of the same major version.
SDK ↔ Ingest API	SDK is backward compatible within a major version of the API.

See the Versioning Policy for the full compatibility matrix.