Architecture approved · Production migration is a separate phase
On-Premises to AWS
Redesigning a university hosting environment for availability, security, and recovery.
- AWS
- Architecture
- Migration Planning
The starting point
I inherited two Ubuntu servers running Apache, PHP-FPM, and WordPress Multisite, hosting approximately 67 websites. Documentation was fragmented, monitoring was absent, and there was no staging environment or clear disaster recovery plan.
Prepare before migrating
I stabilized PHP-FPM, corrected permissions, introduced uptime monitoring, and established snapshots before major changes. A site inventory and ownership audit reduced the active portfolio to 29 websites, simplifying operations and the scope of the proposed migration.
The approved architecture
- EC2-based WordPress hosting across multiple Availability Zones.
- RDS for MySQL with Multi-AZ availability, automated backups, and isolated databases per site.
- S3 for media storage and CloudFront for content delivery.
- WAF for edge protection and cross-region passive disaster recovery.
Decisions and tradeoffs
Multi-AZ infrastructure adds cost and operational complexity in exchange for reducing dependence on a single server. Managed database services reduce database administration work but add recurring cost. Moving media to S3 separates it from application servers while introducing integration work.
Passive cross-region recovery balances recovery requirements against the expense of running a second fully active environment. I also proposed separating WordPress Multisite into individual installations: better failure isolation, with additional fleet management that would need automation.
Review and current status
I documented the architecture and incorporated feedback from university IT leadership and an AWS Senior Solutions Architect. The migration blueprint was approved. The operational improvements are complete; the proposed AWS architecture is not presented as an already completed production migration.