Pearl Platform

Set up a completely separate Azure home for the test environment so it is isolated from production from day one.

1. Create or confirm the dedicated test subscription and set a budget alert at the agreed monthly threshold.
2. Create the hub, spoke, and data resource groups in UK South.
3. Apply the required tags and assign the initial infra and QA access roles.

Create the secure entry point that administrators use to reach the environment and that controls outbound traffic.

1. Create the hub VNet with the Bastion and Firewall subnets.
2. Deploy Azure Bastion so remote access happens without public IP addresses on the servers.
3. Deploy Azure Firewall and add the first outbound allow rules for GitHub, NuGet, Azure storage, and approved sandbox vendors.

Create the private network where the Pearl servers and database live.

1. Create the spoke VNet and carve it into four subnets: web, worker, build, and data.
2. Peer the spoke to the hub so Bastion and Firewall can serve it securely.
3. Attach the route table so internet-bound traffic goes through Azure Firewall by default.

Define exactly which zones are allowed to talk to each other and on which ports.

1. Create one NSG per subnet and start from deny-by-default thinking.
2. Add only the flows Pearl needs, such as web to database, worker to web, and Bastion to RDP.
3. Attach the NSGs to the right subnets and validate the rules match the design table.

Create a secure place to store secrets so credentials are not embedded in code or manual notes.

1. Create the Key Vault with soft-delete and purge protection enabled.
2. Load the first set of secrets, including database connections and sandbox integration keys.
3. Grant only the required read permissions to the server identities that will consume those secrets.

Create the storage area for backup files, scripts, and deployment artifacts.

1. Create the storage account in UK South with the right redundancy and access settings.
2. Create the backup, restore, and scripts containers.
3. Enable lifecycle cleanup so old backup blobs are deleted after 28 days.

Create the test database platform that will hold all 17 Pearl databases.

1. Start SQL Managed Instance creation early because Azure takes several hours to finish provisioning it.
2. Place it in the data subnet, disable public access, and wire in private DNS.
3. Create the required test logins and validate basic connectivity from the future application subnets.

Create the web server that hosts the Pearl front end, internal web services, cache, and search.

1. Provision the VM in the web subnet, harden the OS, and enable disk encryption and patching.
2. Install IIS, create the application pools, and configure the five sites with the right paths and bindings.
3. Install Memcached and Solr, then add the host-file entries and shutdown schedule that mirror the design.

Create the worker server that runs background processing away from the user-facing website.

1. Provision the VM in the worker subnet and install the required .NET runtimes and Windows features.
2. Create the folder structure for queue processing, health checks, AI spooler, Totem, and logs.
3. Register each executable as a Windows service, add the host-file mappings, and set the shutdown schedule.

Create the server that compiles code, runs deployments, and executes restore tooling.

1. Provision the VM in the build subnet and harden it like the other servers.
2. Install Visual Studio Build Tools, .NET targeting packs, Git, and NuGet tooling.
3. Create the restore-tools directory and confirm the machine can reach GitHub, storage, and the internal servers.

Give each VM a secure identity so it can retrieve secrets without using hardcoded credentials.

1. Enable a system-assigned managed identity on VM1, VM2, and VM3.
2. Grant the minimum Key Vault access needed for each server's role.
3. Test that each VM can retrieve only the secrets it actually needs.

Create the safe file-based handoff from production to test.

1. Create the production SQL credential that can write backup files to the test storage account.
2. Schedule weekly backups for all 17 databases to the backup container.
3. Run an initial test backup and record real file sizes for planning and validation.

Automate the download and restore process so refreshes become repeatable instead of manual.

1. Write the PowerShell function that downloads the newest backup files from Azure Blob Storage.
2. Write the restore sequence so databases come back in the correct order and required logins are recreated.
3. Add validation checks and a summary report so the run clearly says pass or fail.

Remove or replace personal information before any non-production users touch the refreshed data.

1. Create one masking script per high-risk database, starting with PearlData, PearlUsers, and PearlBilling.
2. Replace names, phones, emails, addresses, bank details, card references, and message text with safe test values.
3. Run sample checks against each masked table to prove the sensitive fields no longer contain live data.

Force the restored environment to use sandbox settings so it cannot hit live services.

1. Create the post-restore SQL script that replaces live API keys and endpoints with test values.
2. Disable risky actions such as live SMS sending and swap payment providers into test mode.
3. Verify key ConfigStrings now point to the worker server, sandbox integrations, and the internal Solr endpoint.

Prove the refresh process works from start to finish and leaves the test environment safe.

1. Run the full sequence: backup, download, restore, mask, override, and validate.
2. Spot-check records in every masked database to confirm that sensitive fields are actually anonymised.
3. Measure the total runtime, document the process, and publish the restore runbook.

Connect GitHub securely to the private build server inside the Azure network.

1. Download the self-hosted runner package onto VM3.
2. Register it to the repository with the agreed labels and runner group.
3. Install it as a Windows service and confirm it shows online in GitHub.

Automate the compile-and-package part of the release process.

1. Create the workflow file that triggers on the agreed branches.
2. Run checkout, restore packages, and build all required components using the self-hosted runner.
3. Package and publish build artifacts so the deploy workflow can consume them.

Automate deployment with approval, rollback, and basic health checks.

1. Create the manual or chained deploy workflow and protect it with the test environment approval gate.
2. Stop the target services, copy in the new artifacts, and keep a rollback copy of the previous version.
3. Restart the sites and services, then run health checks against the main endpoints.

Turn the restore script from Phase 3 into a repeatable scheduled operation.

1. Create a workflow that calls the restore script on VM3.
2. Schedule it for the agreed weekend slot and allow manual triggering when needed.
3. Add success and failure notification steps so the team knows the outcome.

Prove that build, deploy, rollback, and refresh all work reliably.

1. Run at least two successful build and deploy cycles end to end.
2. Run one forced failure or rollback scenario and confirm recovery works.
3. Document the workflows, approvals, and support actions in the runbook.

Prove that the test environment is walled off from live systems.

1. Check that there is no network peering from test to production subscriptions.
2. Run connectivity tests from the test VMs to production endpoints and confirm they fail.
3. Review firewall, disk encryption, and Key Vault access logs to confirm only approved paths exist.

Make sure every person and system has only the access needed for their role.

1. Create the six custom roles and scope them to the correct resources.
2. Assign people and service principals to those roles based on their job responsibilities.
3. Enable PIM so high-risk access requires approval and automatically expires.

Turn secret handling into a governed process instead of a one-time setup.

1. Define the 90-day rotation plan for secrets and the annual rotation plan for encryption keys.
2. Create alerts for upcoming expiry and unusual secret-access behaviour.
3. Enable customer-managed keys for disk, SQL, and storage encryption where required by the design.

Create the evidence trail needed for support, investigation, and compliance.

1. Create the audit database and the required tables for security and operational events.
2. Add triggers or application capture points to record logins, changes, and release actions.
3. Test the audit path by performing sample actions and confirming the records appear correctly.

Add active monitoring and guardrails so the environment stays secure after go-live.

1. Create the Log Analytics workspace and connect the VMs and key Azure resources.
2. Add alerts for server availability, SQL pressure, and failed deployment events.
3. Apply policies that block public IPs, enforce required tags, and restrict deployment to UK South.

Prove the environment works for the key business journeys that matter most.

1. Test the operator journey, client portal journey, and core background-service behaviour end to end.
2. Verify the queue processor, system checker, and Totem are all functioning and updating the right backend records.
3. Confirm risky integrations are safely sandboxed, including Stripe test mode, SMS disabled mode, and Mailgun sandbox routing.

Create the material the team will rely on after the build team steps away.

1. Write the deployment, backup and restore, troubleshooting, secret rotation, and VM operations guides.
2. Update the architecture diagram so it shows the final live IPs, hostnames, and component placement.
3. Review the documents with the operations team to make sure the language is understandable and usable.

Transfer knowledge so the internal team can run the environment without depending on the project team.

1. Run a live walkthrough of deployment, restore, rollback, and support procedures.
2. Record the session and store it with the rest of the documentation set.
3. Confirm named owners, support responsibilities, and formal handover acceptance.

Convert the one-off build into reusable infrastructure-as-code.

1. Replace hardcoded names and addresses in the templates with environment variables or parameters.
2. Create repeatable modules for the 3-VM plus database pattern.
3. Test that the same templates can create a second environment without changing the code manually.

Make every environment easy to identify and impossible to confuse with another one.

1. Define the environment naming pattern for subscriptions, resource groups, VMs, and Key Vaults.
2. Assign a clean network address range for each future environment.
3. Document the convention so new environments follow the same pattern every time.

Make sure deployments and secrets stay inside the correct environment boundary.

1. Create separate secret sets and environment names for each cloned environment.
2. Update the build and deploy workflows so the correct target can be chosen safely.
3. Test that environment A cannot accidentally deploy into environment B.

Prove the cloneable design works in reality, not just on paper.

1. Run the IaC templates to create a second environment using the agreed naming and addressing rules.
2. Deploy a small validation build into it and confirm the core services come up.
3. Record the evidence so the multi-environment capability is demonstrably complete.