The week after a launch is its own discipline. Where the previous seven days had been about decisive action — DNS lowered, traffic flipped, certificates provisioned, the company website live on Azure for the first time — this week was about watchful attendance. Twelve items to Done, almost all of them quiet and operational: Phase 7 closed as an epic, telemetry sharpened, uptime watched from the outside, off-site mirrors and archives put in place, and an enterprise e-commerce go-live moved into its post-cutover hyper-care phase.
The headline close-out was Phase 7 — DNS cutover itself. The epic that had carried the work from the apex-record flip through SSL provisioning, GoDaddy domain-ownership hardening, and the final pre-cutover sanity checks reached Done as a whole on Monday, the seven-day live observation window now in motion against the new SWA. The same day, external uptime monitoring went live: both the apex and /api/health are now polled every five minutes from outside Azure, with email alerts routed to an off-domain address so an outage cannot suppress the page about itself. A small but pointed bit of defence in depth — if the site is down because mail is down, the alert still arrives.
Alongside that came a piece of post-launch verification that could only be run against the live production hostname: the X-Forwarded-For trust-model probe. The §9.3 in-memory per-IP rate limiter on the contact endpoint depends on the function reading a trusted client IP — but the trustworthiness of X-Forwarded-For's leftmost entry depends entirely on what the SWA edge proxy does with a client-supplied XFF on inbound requests. If the edge appends to a spoofed header rather than replacing it, the limiter keys against attacker-controlled data and the 30-second per-IP gap becomes bypassable per request. A controlled curl from a workstation with a known public IP, paired with a salted-SHA256 hash check against the corresponding row in the submissions table, confirmed the live trust model behaved as we wanted it to. The result was documented as a code comment against the trust assumption in GetClientIp — close the ticket, leave a note for future-you.
Telemetry was refined alongside. The four §9.11 input-hardening rejection paths in ContactFunction — oversized body, wrong content-type, deep-JSON, unknown-property — had until this week shared the generic Outcome=validation-error audit value with schema validation failures. Spec-conformant against v1.21's "either acceptable" stance, but operationally lossy: a bot probing the deserialiser couldn't be cleanly distinguished from an honest user mistyping a field name. Each path now emits its own specific audit value — oversized, bad-content-type, deep-json, unknown-property — while the wire response shape stays unchanged at 400 with body {"error":"validation"}. The functional test fixtures were extended to assert the new Outcome value alongside the existing 400 assertion in each case. Forensics-grade improvement; no externally observable change.
— On the week after —Launch is a moment. Stewardship is the practice that follows.
The stewardship work continued on the backups-and-mirrors side of the house. A final WordPress export from the IONOS managed install was taken — full content export, the wp-content/uploads/ media tree via SFTP, a database backup — and stored in two durable locations against the eventual cancellation of the hosting plan. The migrated entries are already on the new site, but a full archival means nothing is lost if a future content question arises about something the migration didn't carry across. Separately, an off-GitHub repository mirror went in — a nightly Action that pushes the repository to a personal GitLab account against the small but non-zero risk of GitHub account compromise, accidental repository deletion, or vendor incident affecting account access. The initial implementation pushed hidden remote-tracking refs by mistake and was caught quickly; the fix — a bare clone in the workflow, so only first-class refs are mirrored — landed mid-week. Recovery path documented in the controller's compliance folder so a future me knows how to restore.
The progressive migration of the older WordPress journal backlog began in batches, the new editorial voice applied to each entry as it lands on the new site. There is no hard deadline — a cadence of three to five entries a week alongside any new authoring is enough — and the journal index can honestly carry a note that older entries are being progressively re-published.
In parallel, the enterprise e-commerce engagement entered its post-go-live hyper-care phase — the period after every well-run cutover where the operator stays close to the live system and dispatches the small operational defects that only emerge under real traffic. Three were investigated and resolved this week: a SKU lookup error, a product-code lookup that needed normalisation against the actual data shape in production, and a clutch of supplier-lookup errors. None individually dramatic; collectively, the unglamorous follow-through that distinguishes a competent post-launch period from one where defects accumulate. The Salesforce graph-style conversion shipped the previous week appears to be holding up well under live load.
For retained clients, small but useful pieces of operational work landed alongside: a web-form data cleanup pass for a veterinary practice, and the slow administrative work of chasing a treasurer handover for a community club — the kind of low-key stewardship that keeps small organisations functioning.
Looking ahead, the seven-day live observation window continues to its close, after which we proceed to the cancellation of the IONOS managed WordPress hosting itself. The §14.3 monthly submission audit log CSV export is queued — the small ritual that turns the submissions table from operational telemetry into a documented controller-side compliance artefact. And then the final registrar/DNS-host realignment: migrating DNS authority from IONOS back to GoDaddy, now that the cutover is complete and the apex is comfortably resolving to Azure. With that done, the company-website infrastructure programme closes out, and the new chapter properly opens for ordinary business.
Twelve items to Done. A launch left to settle. A long-running epic closed as a whole. And the post-launch caretaking — the part nobody photographs, but which determines whether last week's work holds up over the months that follow — quietly underway.