Status
This guide is being written
Do not start an AWS upgrade from this page yet. The procedure is being documented and nothing below is a complete instruction. Contact the BLiNQ support team to plan an AWS upgrade.
An AWS upgrade is not the on-premise procedure run in a different place. On your own servers the platform is backed up, restored into a staging cluster and promoted in place. On AWS a second environment is built alongside the running one and traffic is moved across by DNS, which changes what you prepare, what the downtime window covers, and how a rollback works.
Running on your own servers instead? The procedure for that is documented in full: see the on-premise upgrade operator guide.
Outline
What this guide will cover
The sections below are placeholders. Each will be filled in with the exact commands, the checks that gate each step, and what to do when a check fails.
Before you begin
Who runs the upgrade, what access is needed, and the state the running environment must be in before anything starts.
Preparing the second environment
The inputs that describe it, the network and DNS zones involved, and what must exist before it is built.
Standing it up
Building the new environment beside the running one, and confirming it is healthy before any data moves.
Moving the data
What is copied, in what order, and what the downtime window actually covers.
The cutover
Moving traffic across, the checks that must pass first, and how to confirm it landed.
Rolling back
Reversing the cutover, what is recoverable at each stage, and the point after which rollback is no longer simple.
Decommissioning
Removing the old environment once the new one is proven, and what to keep.
If something goes wrong
The failures seen in practice, how each one presents, and the recovery for it.
In the meantime
Planning an upgrade now
If an AWS deployment needs to move to a newer release before this guide is finished, raise it with BLiNQ support rather than improvising. Useful things to have ready when you do:
- The release you are on now, and the release you are moving to.
- Which AWS account and region the deployment runs in, and whether it is a public or private deployment.
- Whether the images come from BLiNQ's registry or your own ECR.
- The maintenance window you can offer, and who needs to approve it.
Installing a new AWS deployment rather than upgrading one? That is documented in full in the AWS installation guide.