appfarms.com – from WordPress to Astro

About this project

This reference is an in-house project: the migration of our own website appfarms.com from a WordPress installation that had evolved over many years to a statically delivered Astro stack. We document the project openly – including the rough edges – for two reasons.

First, because we want to be measured by what we recommend to clients: a modern web that is fast, secure, maintainable and durable. Second, because the pain points that triggered our migration are the same in many companies – and a practical account of the work is worth more than any glossy bullet list.

Starting point: what no longer fit on WordPress

The old site ran reliably – but it kept demanding attention without delivering editorial benefit in return:

• Plugin and core updates as a recurring maintenance task, with the risk of incompatibilities and breaking changes.
• Security surface: PHP runtime, database, third-party plugin code and a public login – every element is a potential attack vector and requires patch discipline.
• Performance: pre-built HTML and locally hosted fonts reduce the work needed to load a page. We use Lighthouse for technical checks; real loading times also depend on the device and connection.
• Editor and page-builder fragmentation: content was partly in the block editor, partly in the page builder, partly in plugin custom fields. Structured content (case studies, FAQs) was hard to keep consistent.
• Reproducibility: staging and local environments were laborious; database and media sync was a recurring source of friction.

None of this is an argument against WordPress in general. For our profile – a primarily editorial marketing and references site with a moderate change cadence – the ratio of complexity to benefit had simply become unfavourable.

Maintaining the previous website

A WordPress installation needs regular maintenance of its core, plugins, access controls and server configuration. For our mainly editorial website, we wanted to reduce that ongoing work. Static delivery removes the WordPress runtime from the public site; the web server, dependencies and security configuration still require maintenance.

Decision: why Astro

We seriously evaluated three options: modernising WordPress (clean-up, plugin reduction, headless frontend), a Hugo/Eleventy solution, and Astro. We chose Astro because, for our profile, it offers the best combination:

• Static delivery – the web server serves pre-built files. There is no need for a PHP runtime, WordPress database or public CMS login.
• Component model with TypeScript, without forced SSR and without framework lock-in. We can drop in React/Svelte islands when needed – but don’t have to.
• Content collections with a Zod schema: content is validated at build time. A missing required field breaks the build instead of going live unnoticed.
• Multilingual setup cleanly as a directory structure (de/, en/), not as a plugin.
• SEO essentials (sitemap, JSON-LD, hreflang, canonical) live in code – versioned and reviewable, not in a plugin backend.

Migration path

1. Content audit: every WordPress page evaluated (keep, rewrite, drop, merge). Result: significantly fewer but stronger pages.
2. Content model before content: schema for pages, case studies and FAQs defined in content.config.ts before migrating content. That surfaced several inconsistencies from the old site.
3. Markdown migration: content carried over as Markdown, images optimised, alt texts added.
4. Redirects: removed pages get appropriate destinations. For example, the former training page redirects to About us.
5. SEO building blocks: JSON-LD for organisation, breadcrumbs, FAQs and case studies; clean <title> and meta descriptions per page.
6. Build and hosting: Astro generates static files, which Nginx serves. The server configuration and container setup are included in the project.

Results

What changed noticeably in practice:

• Maintenance: no plugin updates, no PHP patches, no login hardening. Updates are limited to dependencies that are visible in PR review.
• Performance: pre-built HTML and locally hosted fonts reduce the work needed to load a page. We use Lighthouse for technical checks; real loading times also depend on the device and connection.
• Editorial workflow: a new reference or service equals a new Markdown file with a schema. Consistency is enforced by the system, not by discipline.
• Security: WordPress runtime endpoints are no longer part of the site. HTTP security headers are configured separately in Nginx; static delivery does not provide them automatically.
• Operations: the website needs neither a separate WordPress database nor a PHP runtime, simplifying the infrastructure.

Lessons learned – honestly

• The content schema is the most important decision, not the framework. Whoever defines the data structure cleanly wins regardless of stack.
• Content and URLs need their own planning. The technical framework is only one part of the migration.
• Astro is not the right choice for every site. For highly dynamic, logged-in or heavily editorial scenarios, other stacks may fit better.
• “No CMS” does not mean “no editorial process”. With a non-technical team, plan in a lightweight editor frontend – Astro keeps that option open.

What does this mean for your project?

If you run a website that primarily serves marketing, reference or product content, where security and performance are high priorities and maintenance effort has become noticeable, an Astro-based stack deserves an honest look. We support migrations like this – from content audit through schema design to an SEO-preserving go-live. Feel free to get in touch.