CyberAcademy goes live: WordPress, Amelia, DNS cutover and every mistake we learned from

Situation

On 27 October 2026, an intricate migration moved CyberAcademy.hu to a new production application and operations model. The job went far beyond the visible front end: legacy WordPress, historical Amelia bookings, multilingual routes, legal content, private CGI services, outbound SMTP and DNS all had to be handled. The result needed to retain the client’s original identity while making registration for cybersecurity leadership training operational and auditable. This is a record of the engineering decisions, the verified outcomes and the very real missteps made by both the AI assistant and our shared process.

Approach

We separated business-critical data and appearance from removable WordPress dependencies, then reconstructed the interface using the actual source styling. Amelia was treated as an operational migration rather than a read-only archive; CGI and email were given independent checks. Engine consolidation, cross-platform Make fixes, multilingual QA, SHA-pinned release assets and DNS validation were carried out as guarded steps, not an unchecked big-bang switch. Production deployment was followed by a distinct Live QA run with stored browser and Lighthouse artefacts.

1. The assignment: a new website with a live booking workflow

Moving cyberacademy.hu was never just about replacing page markup. The original WordPress site handled real training courses, customer contact and Amelia bookings. We had to preserve its visual identity, information and historical records while reducing WordPress dependencies. Email remained a deliberate dependency on the legacy hosting provider, too: changing a website and migrating business mailboxes are different operational changes.

2. Visual fidelity instead of invented AI design

Early in the migration, the assistant proposed an entirely fictional blue design instead of the evidence-based lavender and magenta styling. That was an engineering mistake, not a subjective design choice: migrating an existing client website means respecting the approved original. We returned to the captured source, genuine CyberTeam artwork, locally hosted Space Grotesk and the #eef0ff / #9f376d colours. A regression test now guards against bringing back the rejected blue theme. We also corrected real layout defects affecting the header, image spacing, card grids and responsive margins.

3. Amelia: operational migration, not a read-only museum

Historical Amelia records were not supposed to end up in a read-only showcase. The owner needed to keep managing sessions and bookings through a functioning, writable administration flow. Our first read-only approach was a dead end. We reconciled source bookings, events, IDs and payment associations, then made final SHA-256 verification and private server-side staging explicit gates for the last migration copy. Importing based on an outdated assumed booking count would have been irresponsible: the final live data has to be checked, not guessed.

4. The Make, macOS and Python failures

The commit history from today contains a fair share of unglamorous fixes. We mishandled dollar-sign escaping in GNU Make recipes, so shell variables and command substitutions could disappear during expansion. On macOS, /var and /private/var resolve to the same filesystem location but were incorrectly compared as different paths. Python 3.15 removed the legacy load_module call we had relied on. These were preventable cross-platform compatibility defects. We repaired the code and added focused regression tests instead of pretending that a green local command had proved portability.

5. CGI, SMTP and the interrupted SSH confirmation

A functional booking or contact form requires much more than a convincing interface: server-side validation, private SQLite state, a mail queue and delivery through real SMTP all matter. One failure mode was especially awkward: an SCP upload completed but the subsequent SSH confirmation failed, leaving the operator unsure what had actually finished. Blind retries were not safe. We implemented resumable staging, tighter SSH handling, explicit state checks, SHA-pinned CGI runtime upgrades and rollback guards. Isolated tests exercised contact messages, Amelia POST behaviour and actual email delivery paths.

6. KampányMűvek Engine and real quality gates

We replaced WordPress rather than replacing it with another disposable set of project-specific scripts. The result uses the version-locked KampányMűvek Engine. But we initially maintained overlapping site-owned and Engine-owned CI/deployment paths, adding needless complexity and confusing failed checks. We consolidated the canonical Engine flow while keeping Amelia and contact regressions. Frontend and runtime Make deployment targets now require the quality gate; the multilingual consent stylesheet and workflow checksums also received dedicated regression coverage.

7. DNS cutover: measurable, not magical

The public domain ultimately moved to the new server at the new hosting server. There is no magic button to flush every DNS resolver worldwide at once. We inspected resolution and route responses; explicit origin testing with curl --resolve verified HTTP 200 and a successful TLS certificate check from the new host. The owner independently reached the new page on a phone. We added a live sitemap check from the public domain as well, while acknowledging that Google Search Console ownership and indexing are separate processes.

8. What a passing Live QA actually proves

The production release on 27 October 2026 was promoted with a specific commit SHA, a GitHub Actions deployment and a successful follow-up Live QA run. The browser artefact contains genuine desktop and mobile screenshots, with Lighthouse reports recorded separately. That is valuable evidence for the inspected routes and deployment, not a claim that every booking, payment, mailbox or future configuration has been exhaustively tested. When email moves to Microsoft in the future, the web application’s SMTP configuration and delivery behaviour will need another controlled change.

9. Accountability rather than heroic debugging

My mistakes as the AI assistant included inventing a blue theme, proposing an inappropriate read-only booking detour, overstating confidence and allowing deployment logic to sprawl. We also made shared process mistakes: rushing toward a convenient fix increased the amount of QA work, and repeated CI patches sometimes obscured what was actually deployed. The way forward is not to hide this. We need traceable source evidence, precise release fingerprints, deterministic tests, reversible changes and documentation written for developers, not for the people who happened to build the system. The result is now a working production migration rather than a theoretical redesign.

Outcome

The multilingual CyberAcademy.hu site is now served from the new KampányMűvek-based production environment, with origin-level HTTP 200 and valid TLS confirmed in the inspected checks. The production deployment and subsequent Live QA on 27 October completed successfully, and the QA browser artefact supplied an authentic screenshot for the portfolio. Database, CGI, SMTP and migration safeguards have auditable checkpoints; the completed tests cover the routes and behaviours actually inspected, not every possible future scenario. Email still depends on the legacy host for now. An eventual Microsoft mail move and separate Search Console access require their own controlled actions.