How I moved ralpe.eu to a modern AWS Lightsail environment—and what I learned about WordPress, server administration, and collaborating with artificial intelligence.
In October 2026, I decided to modernize the server infrastructure behind my personal blog, ralpe.eu. The site had run for several years on Amazon Lightsail using a WordPress Multisite installation originally packaged by Bitnami. It had served me well, and I had little reason to think about the server while concentrating on the blog itself.
But the underlying software was aging. I needed an up-to-date operating system and PHP environment without rebuilding WordPress, changing the content, or disrupting the established URLs. The migration became an experiment in something else as well: I carried out the entire process in dialogue with ChatGPT.
Why the old Bitnami installation needed replacing
I had created the original server in 2022 using a Bitnami-packaged WordPress Multisite blueprint offered through AWS Lightsail. Bitnami images made it convenient to deploy a complete application stack rather than configure WordPress, Apache, PHP, and the database separately. I wrote about the original setup in my February 2022 article, Installing Bitnami WordPress Multisite on AWS Lightsail.
By 2026, however, the situation had changed. The AWS Lightsail console described my older instance as “Originally packaged by Bitnami (no longer maintained).” In other words, that particular legacy blueprint was no longer maintained as a current Lightsail offering. This should not be confused with a claim that WordPress—or Bitnami as a whole—had stopped being maintained.
My WordPress installation was current, but the underlying Debian and PHP environment was not. Updating WordPress in its dashboard does not upgrade the operating system or all the components beneath it. Rather than attempt an operating-system upgrade on a production server with years of accumulated configuration, I chose to migrate to a fresh Lightsail WordPress Multisite instance.
Building a replacement while the old site stayed online
The central decision was to prepare the new server alongside the old one. That gave me time to configure the replacement, migrate the data, and verify its behavior before changing where visitors were sent.
The new Lightsail blueprint provided a more modern Debian environment. I brought PHP up to version 8.4 and checked that Apache was actually using the new PHP installation. I also created recovery snapshots and kept the old server intact as a fallback.
I deliberately separated the infrastructure migration from any redesign of the blog. The goal was continuity: the same WordPress content, links, appearance, and administration, running on a better-maintained foundation.
A migration conducted as a conversation
ChatGPT did not log into AWS on its own and move the site autonomously. Instead, the process unfolded step by step through our conversation. I described the current setup and my objectives; ChatGPT proposed checks and terminal commands; I ran them, returned their output, and asked follow-up questions whenever something was unclear.
This dialogue was especially valuable when a command did not give the expected result. We could examine the actual output, adjust the next step, and verify that the change had worked before proceeding. I remained the person executing commands, controlling access, and deciding when to make changes to the live system.
The method was slower than a single “migrate everything” script, but it kept the work understandable. Backups, inspections, and verification points became part of the process rather than afterthoughts.
Moving WordPress content and configuration
A WordPress migration involves at least two different kinds of data. The database stores articles, settings, users, and the relationships that make the site function. The files contain themes, plugins, images, and other uploaded content. Both needed to move together.
We exported the database, transferred it securely, and imported it into the new MariaDB installation. We also copied the WordPress content files using secure transfers, including rsync, which is useful for moving large directories and checking subsequent changes.
The old Bitnami installation and the new Lightsail blueprint used different directory layouts. That meant we could not simply assume that a path or permission from one system would apply unchanged to the other. We checked WordPress Multisite settings, filesystem permissions, themes, media, and the relationship between WordPress and its new web server.
Caching components also required care. Some WordPress caching files operate very early in the application’s startup process, so we preserved the relevant settings while keeping potentially incompatible cache drop-ins out of the initial migration. The priority was a correctly functioning site before performance tuning.
Transferring the existing SSL certificate before the switch
An important part of the preparation was HTTPS. The old server already had a valid Let’s Encrypt certificate, and I did not want the move to interrupt secure access to ralpe.eu.
Before reassigning the static IP address, we securely transferred the existing SSL certificate and its private key from the old Bitnami instance to the new server. We verified that they matched, configured Apache to use them, and tested encrypted connections on the replacement instance while the public site was still served by the original one.
These tests were possible without changing public DNS records: requests could be directed to the new server while retaining the correct domain name for HTTPS verification. This was an especially useful safeguard because it separated certificate problems from the eventual production switch.
Reassigning the static IP and going live
After checking the migrated WordPress installation, media, and HTTPS, we reached the cutover. I stopped the web service on the old server and reassigned the existing Lightsail static IP address to the new instance.
Keeping the same public address simplified the migration. There was no need to replace the blog’s existing IPv4 DNS record and then wait for a new address to propagate.
We verified that ralpe.eu responded from the new server and that its HTTPS certificate validated correctly. The blog was now running on the new infrastructure, while the previous instance remained available in case a rollback became necessary.
Configuring certificate renewal after the cutover
Transferring the old certificate had ensured continuity during the switch, but it was not a long-term certificate-management strategy. Only after the new server was serving the public website did we install Certbot and obtain a new Let’s Encrypt certificate.
We configured automated renewal and a deployment hook so that Apache could reload newly issued certificates. A simulated renewal succeeded, showing that Certbot could complete the certificate-validation process. The hook’s execution was a separate operational check, so the successful dry run should not be mistaken for proof of every possible future renewal scenario.
This two-stage approach—reuse a valid certificate for the move, then establish a maintained renewal process—helped avoid making certificate issuance a prerequisite for the actual server switch.
The unexpected problem: an unresponsive server
The cutover worked, but not everything went smoothly afterward. On two occasions, the new server stopped responding to website requests and even to the browser-based SSH connection in Lightsail. Rebooting restored access, but the repeated incident made it clear that the new environment needed attention.
We inspected system logs and resource usage. There was no conclusive evidence identifying a single cause of the outages. One issue did stand out, however: Apache’s default process settings were overly generous for the resources available to this instance.
Apache workers handle incoming requests, and each worker can consume memory. We reduced the permitted number of simultaneous workers and adjusted how idle workers were managed. After the change, the server showed more available memory, and ralpe.eu continued responding normally.
That improvement was encouraging, but I would not claim that it definitively explained the earlier failures. A configuration can deserve correction without being proven to be the cause of an outage. Long-term stability still requires observation.
What working with ChatGPT taught me
The experience made several strengths of conversational AI quite tangible. ChatGPT could retain the context of the migration, explain unfamiliar Linux and WordPress concepts, and propose a manageable next step instead of leaving me to assemble disconnected tutorials.
It also demonstrated why AI-assisted administration needs human judgment. A plausible diagnosis is not necessarily a verified one; commands must be evaluated against the actual environment; and a successful test at one moment does not guarantee long-term reliability.
I found the most useful working pattern to be simple: inspect first, preserve a fallback, change one thing, test the result, and then continue. The conversation itself became useful documentation of the decisions we made.
I would not publish that complete technical record. It contains operational details that are valuable for maintenance but unnecessary for readers. A public account can explain the experience without disclosing private credentials, internal paths, server addresses, or detailed resource constraints.
What I would do differently next time
I would examine the replacement server’s resource configuration earlier, establish monitoring before the cutover, and keep a clearer distinction between migration success and evidence of long-term stability.
I would still favor building a replacement alongside the production server. Being able to test WordPress and HTTPS before changing the public endpoint made a complicated operation considerably easier to manage.
Conclusion: modern infrastructure, with the human still in control
The core migration of ralpe.eu succeeded: the blog retained its WordPress installation and content while moving to a newer AWS Lightsail environment. Public HTTPS works, certificate renewal has been configured and tested, and the web server has been tuned more conservatively. Further administration checks and stability monitoring remain sensible follow-up tasks.
For me, the most interesting part was the collaboration. The entire migration was conducted in dialogue with ChatGPT—not as a fully autonomous operation, but as a sequence of questions, explanations, commands, observations, and decisions.
AI did not eliminate the technical complexity or the need to be careful. It helped make that complexity approachable. In that sense, the most useful role of conversational AI may be not to replace human responsibility, but to enable people to carry out technical projects they might otherwise hesitate to attempt.
Leave a Reply