WordPress to Astro: rebuilding the OSI Global website

osiglobal.com

OSI Global is a privately owned, Gartner-recognised provider of third-party maintenance, optical networking, enterprise hardware and data-centre services — in business since 2008. Their site ran on WordPress. We rebuilt it on Astro: a faster, static site OSI owns outright, editable by their own team — or directly through Claude and ChatGPT — with every lead landing in HubSpot.

Why they moved off WordPress

WordPress got OSI a working site. What came with it was the usual tax: a database and a PHP runtime on the critical path, a stack of plugins to keep patched, and a performance ceiling set by the theme rather than the content. For a company whose pipeline runs on inbound enquiries — someone comparing maintenance providers on a phone and filling in a quote form — that ceiling shows up where it costs money: mobile load time, and how long it takes to publish a new service page or a campaign landing page.

What we built

The site is now static. Every page ships as pre-rendered HTML built with Astro. There is no database query and no PHP runtime between a visitor and the page — the server just hands over a file. On this build the root document responds in 200 ms, and there is no render-blocking CSS: every stylesheet is inlined into the HTML at build time.

Content lives in Git, not a database. Service pages, the blog, news, case studies and the paid-ad landing pages are files in the repository, edited through Keystatic — a Git-based CMS. Each edit is a commit, so the content has the same history, review and one-click rollback as the code. Thirty-seven blog posts were migrated off WordPress into this system, with native Astro image optimisation handling all inline post media.

The team can edit the site in plain English — or with AI. Two ways in. There is an on-page visual editor: an authorised editor opens any page, clicks the text, types, and saves. And because every piece of copy is a plain file in the repository, the same content can be edited directly through Claude or ChatGPT — describe the change, get a pull request instead of a support ticket.

The editor is a separate, locked-down deployment. Keystatic and the visual editor run on their own Cloudflare Worker behind Cloudflare Access. The public site ships as pure static files with no admin surface attached to it — nothing to brute-force, nothing to keep patched. An editor saves, that becomes a commit, the commit triggers a build and deploy.

Searchable hardware, not a static price list. OSI handles a large volume of B2B hardware SKUs. We split the global data tables by manufacturer to keep page generation fast, then built a React catalog interface with free-text search and advanced filtering. Buyers browse inventory and submit quote requests that route straight into HubSpot. The tables collapse to clean cards on mobile.

Leads go where the sales work happens. Every form on the site — the quote request, the service enquiries, the campaign landing pages — posts into HubSpot, where OSI's deal flow already lived. No export, no re-typing.

Campaign pages ship in minutes, not sprints. The Dell, Cisco, Supermicro and TPM paid-ad landing pages run off one shared layout driven by a single config file each — so a new vendor landing is a few lines plus its copy, at the exact URL the live Google Ads campaigns already point at.

Results

The whole point of leaving WordPress was speed and ownership. Both are measured, not estimated — these are Lighthouse figures from the live site on 1 October 2026 (Lighthouse 12.8.2):

Metric	Desktop	Mobile
Performance score	98	75
Largest Contentful Paint	1.0 s	3.1 s
First Contentful Paint	0.7 s	2.0 s
Total Blocking Time	0 ms	~670 ms
Cumulative Layout Shift	0	0
Speed Index	0.9 s	2.0 s

Accessibility 92 and SEO 92 on both. The server itself responds in 200 ms and the page paints with zero layout shift — the static architecture is doing exactly what it is supposed to. On mobile the remaining weight is third-party marketing JavaScript (Google Tag Manager, Hotjar, ZoomInfo) blocking the main thread; the ZoomInfo tag is already deferred until the first user interaction, and the same treatment on the rest is the clear next win — a tuning job, not a rebuild.

These are lab measurements against the live site; osiglobal.com does not yet carry enough traffic for Chrome's field data to report.

Tech stack

• Astro — static site generator. Every page ships as HTML; there is no runtime framework and no database on the critical path.
• React (TanStack Table) — the interactive hardware catalogs, mounted as islands on otherwise-static pages.
• Keystatic — Git-based CMS. Content entries are files in the repository.
• Markdoc — the editorial content format for blog, news and case studies.
• GitHub Pages + Cloudflare — the public site is free static hosting on GitHub Pages, served worldwide through Cloudflare's CDN and WAF.
• Cloudflare Access — gates the CMS editor, which is deployed as its own Worker.
• HubSpot — every site form routes into OSI's existing CRM pipelines.

Questions we get about this project

Does a WordPress site have to be redesigned to move to Astro?

No. The rebuild is about the engine and the ownership, not a forced redesign. Design decisions are made because they help the business, not because the migration demands them.

Who edits the site afterwards?

OSI's own team. Content lives in Keystatic as files in the repository; an editor saves and that becomes a commit, which triggers a deploy. The same files can be edited through Claude or ChatGPT, which produces a pull request rather than a support ticket.

What happens to SEO during a WordPress migration?

URLs, meta titles and descriptions are inventoried before the cutover and carried across; a sitemap is regenerated on every build so new pages are submitted automatically, and legacy WordPress URLs are redirected rather than broken.

Where does the site run, and what does it cost to keep running?

The public site is static files on GitHub Pages, served through Cloudflare. There is no WordPress host to pay for and no plugins or PHP to patch — which also removes most of the attack surface a WordPress site carries.

Can the same approach work for other enterprise WordPress sites?

Yes. The constraints repeat: aging WordPress, a performance ceiling, forms that have to reach a CRM, and a team that wants to edit their own site without waiting on an agency.

Thinking about moving off WordPress?

This rebuild is our web development service in practice — a faster, fully-owned site your team can edit themselves, or with Claude and ChatGPT. See what the same move off WordPress could do for your site.