Website and platform modernization
WordPress to Next.js migrations, static sites on AWS S3 and CloudFront, with SEO preserved and performance gained.
Context
A body of digital-presence modernization work: sites and platforms running on WordPress or legacy stacks that needed better performance, a smaller maintenance surface, and predictable operating cost.
Challenge
Migrate without losing what already worked. A site with indexing history carries accumulated SEO value: change the stack and drop the URLs, and that value is thrown away.
My role
Architecture, development, infrastructure, and deployment.
Responsibilities
- Migration architecture and content model.
- Implementation in Next.js with static export.
- Infrastructure on AWS S3 and CloudFront.
- Deployment pipeline.
Constraints
- Preservation of existing URLs and hard-won ranking.
- Multilingual content with correct per-language metadata.
- A low operating budget: the solution has to be cheap to keep alive.
Architecture
- Static export: no application server, no runtime database, no CMS attack surface.
- Hosting on S3 with CloudFront distribution.
- A CloudFront Function on viewer-request rewriting clean URLs onto the export's .html objects.
- Per-language metadata, with canonical and hreflang.
Main technical decisions
Replace the CMS with a static export instead of keeping WordPress.
Why
For sites whose content changes rarely, a runtime CMS is a permanent cost: a server, a database, plugins, and a security surface that demands continuous attention. None of it pays for itself.
Trade-offs
- Publishing content now requires a build rather than a browser editor.
- Not suitable for teams publishing many times a day, or for non-technical editorial staff.
- In exchange: operating cost close to zero, no server to maintain, and no plugin vulnerabilities.
Resolve clean URLs at the edge with a CloudFront Function.
Why
Static export emits /page.html, but the public URL must remain /page, including the ones already indexed. Solving it at the edge keeps the export untouched and requires no server.
Trade-offs
- Adds an infrastructure component that must be versioned and deployed alongside the site.
- A bug in the function breaks the entire site, not a single page. It demands care on deploy.
Implementation
- Next.js with App Router and static output.
- Multilingual content with per-locale dictionaries.
- Versioned deployment to S3 with CloudFront invalidation.
- This very site is one result of the approach.
Production concerns
- Long, immutable cache for hashed assets; revalidated HTML.
- CDN invalidation on deploy.
- No application server to operate or patch.
Results
- Removed the application server and the runtime database from these sites' operations.
- Preserved URLs and metadata through the stack change.
- Reduced the maintenance and security surface by removing the CMS.
Stack
- Next.js
- React
- TypeScript
- Tailwind CSS
- AWS S3
- AWS CloudFront
- CloudFront Functions
- WordPress (source)