Deployment approach
Jira database migration and PostgreSQL upgrades
Move Jira's database and upgrade PostgreSQL through a rehearsed plan that protects issues, attachments and the team's daily work.
← All stories and scenariosThe challenge
Build around the work.
A Jira environment needs a database move or PostgreSQL upgrade while people continue to rely on its issues, workflows and integrations. The application, database, attachments and installed apps need a coordinated plan, with a supported destination and a clear way to recover the service.
How the solution fits together
Jira and its files → release-specific database compatibility checks → rehearsed migration or PostgreSQL upgrade → verified application service
Products and software
- Atlassian Jira ↗
- Run the issue and workflow application. Use the deployed edition's version-specific platform guidance to select the database, Java runtime and compatible application components.
- PostgreSQL ↗
- Provide the database platform for the selected Jira release. Check source and target versions, extensions, roles, encoding and collation before choosing a major-version upgrade method.
- Jira migration tools and PostgreSQL upgrade tools ↗
- Use Jira's supported migration procedure when changing database engines. For a PostgreSQL major-version change, choose and rehearse a compatible logical dump/restore or pg_upgrade procedure.
How we deliver it
- Agree a supported destination — Record the Jira edition and release, database engine and version, runtime, installed apps and integrations. Check Atlassian's compatibility guidance for the intended application release. Plan application and database changes separately where the supported route allows it.
- Rehearse with a recoverable copy — Protect a consistent set of the database, Jira home files, attachments and required configuration. Restore them into an isolated test environment with outbound integrations controlled. Rehearse the chosen engine-migration or PostgreSQL upgrade method and time the work against the agreed change window.
- Switch during the agreed window — Pause application writes and relevant jobs, take the final consistent recovery copy and carry out the rehearsed steps. Update the database connection and required application configuration. Test the service before reopening access, then watch errors and integration behavior during the agreed observation period.
- Return a usable service to the team — Have representative users check their work and retain the acceptance results. Document the resulting versions, maintenance sequence, backup schedule, restore procedure and owners. Keep the prior recovery copy for the agreed retention period.
Why it matters
Keep the team's history and working routines usable while making the application and database easier to maintain. A rehearsed sequence makes the change window and recovery decisions clearer to the people who depend on Jira.
What you receive
A version and compatibility record, a rehearsed migration sequence, a complete recovery set, application acceptance results and maintenance instructions for the service owner.
L8DT services behind the solution
How we verify it
Confirm the supported Jira and database combination, then reconcile representative issues, comments, users and attachments. Test sign-in, permissions, searches, workflow transitions, installed apps, jobs and integrations. Compare agreed queries and application response with the baseline. Demonstrate a restore of the complete service, including its files, before closing the change.
Rollback and recovery
Define acceptance and rollback decisions before reopening Jira. Recover the matching application files, configuration and database together using the rehearsed procedure. If people have written new data since the switch, pause the service and follow an agreed reconciliation or forward-recovery plan; returning to the old copy alone would omit those changes.