Bringing a 13-Year-Old Website Into the Modern Cloud

There's a nice symmetry in this one: globaloutreachevent.com was Professor Lawrence's final project for ET-710 as a student, and it has run his ministry for thirteen years. In one evening we brought it into the modern cloud — together. Here is everything we did, the AWS service behind each step, and the collaboration lessons, because both halves are the point.

Where it started

A 13-year-old site: a Dreamweaver/FrontPage build (the tell-tale _vti_ and _derived folders are still in it), 61 HTML pages, ~271 MB, 1,100 objects, hosted as a plain S3 static website over HTTP — no HTTPS. Route 53 pointed the domain straight at the S3 website endpoint. Functional, but stuck in 2013.

What we did, in order

1. Backed it up — before touching anything

aws s3 sync mirrored the entire bucket to disk (989 files, 262 MB), verified complete.

2. Assessed before changing

Mapped the structure: a shared master.dwt template, a jQuery "media device," a PayPal donate button on 5 pages, S3 website index document = default.html.

3. Converted it faithfully — content first, cleanup later

A multi-agent AI workflow converted 60 pages in parallel into a clean, responsive modern shell — preserving every word, image, video, link, and the PayPal button verbatim; dropping dead Flash; upgrading http:// media to https://.

4. The security incident — the most important lesson of the night

The conversion surfaced things humans had long forgotten — files sitting in the public bucket that didn't belong: a DB-credentials note, a file flagged as AWS keys, and leads.txt: 8,245 rows of contact PII, all publicly downloadable.

• The AI agent refused to publish the credentials file.
• We removed the exposed files — but note: the safety system blocked deletion on production until the human explicitly authorized it. The human holds that gate.
• We triaged: the "AWS secret" file was actually the Amazon Nova documentation (over-flagged; we verified and corrected), and the database in the creds note didn't even exist (a phantom). The only real leak was the PII — now closed.
• Locked the old buckets with S3 Block Public Access.

5. Took it "into the real world" — HTTPS

This is the canonical AWS static-site architecture. Memorize it:

Route 53 → CloudFront (TLS via ACM) → S3

• New website bucket for the rebuilt site (globaloutreachevent-site).
• ACM certificate (in us-east-1, DNS-validated through the Route 53 zone).
• CloudFront distribution: certificate attached, HTTP→HTTPS redirect.
• Verified the new site over the CloudFront URL before changing DNS.
• Flipped Route 53 (apex A/AAAA + www) to CloudFront — carefully preserving every other record (Google mail/calendar/docs, a subdomain). The old bucket was left untouched, so rollback is a single DNS change.

6. Whittled & modernized

Removed dev/experiment cruft; restored the auto-updating copyright year (a tiny browser script — the site's original intent); and a second parallel workflow modernized all 19 content pages (semantic, responsive, legacy table-layouts gone) — again preserving all content + PayPal.

7. Version control

Committed the rebuilt source to AWS CodeCommit, deliberately excluding binaries and secrets, with commit messages that capture why, not just what.

The result

A 2013 HTTP FrontPage site → modern, responsive, HTTPS, secure, version-controlled, backed-up, and reversible — in one evening.

What the rebuild made possible: from brochure to platform

The rebuild didn't just modernize a brochure. The clean, secure static foundation it created became the home of a real authenticated application — the Pastor Portal at /pastor. Churches sign in, watch a live invitation tally, and execute a ministry covenant with a legal e-signature (or download it to sign on paper or in Acrobat), all backed by Cognito, DynamoDB, Lambda-generated PDFs, and email — running for pennies, with no server to maintain.

That is the larger lesson hiding inside a "just rebuild the website" task: a clean static site is not an endpoint — it is a foundation you can build a platform on. A dead 2013 marketing page became a working application. For the full picture of how those pieces fit together — and an honest assessment of what's conventional and what's genuinely novel about the whole stack — see the companion study, How Technically Significant Is This Architecture?

The collaboration lesson underneath all of it

The AI did the labor across every phase — triage, forensics, code, deploy, security, version control. But the human held the three things that don't delegate: intent, authority, and judgment. Prof. Lawrence authorized the production changes, made the DNS-cutover call, and — twice — caught the AI heading the wrong way and corrected it ("there should be no database associated with this site" — and he was right).

That partnership is the method: not "AI replaces the engineer," but a human holding intent and authority, an AI doing the work, each catching what the other can't. That is the operating envelope this course is about.

Quick reference

The collaboration method, in five rules:

1. Back up first — make everything reversible.
2. Preserve, then whittle — never lose content on pass one.
3. The AI surfaces seams; the human authorizes the fix.
4. Verify before cutover; keep rollback one step away.
5. The human holds intent, authority, and judgment — those don't delegate.