From Static HTML to Astro: Migration Complete

In a previous article, I explained why Client Flow Now was gradually moving from a traditional static HTML website towards Astro. At the time, the migration was still in progress. The question was whether changing the architecture would give us a better foundation for a website that was becoming larger and more content-driven.

That part is no longer theoretical - it’s now complete.

Same Website. Different Architecture.

If you visited Client Flow Now before and after the migration, you probably wouldn’t notice much difference That was intentional, this wasn’t a redesign. It wasn’t an attempt to replace a working website. It was a rebuild of what sits underneath it.

The original Client Flow Now website consisted primarily of individual HTML pages. New website is built through Astro, the objective throughout the migration was to preserve what was already working.

I wanted to change how the website itself was organised.

That meant taking things that were previously repeated across individual pages and turning them into shared parts of the website. The result is something visitors may barely notice but which makes a significant difference when working on the project.

Previously, the navigation existed inside multiple HTML pages. If something changed in the navigation, I needed to make sure the relevant pages were updated correctly. Today, the website has its own reusable components, this sounds almost ridiculously simple. Simplicity is exactly the benefit.

A modern business website can have considerably more there than a title and description. Client Flow Now needs to manage things including:

Canonical URLs
Open Graph metadata
Social sharing images
Robots directives
Favicons
PWA configuration
Cookie consent
Google Ads
Meta Pixel
Analytics

During the migration, this was moved into a another shared component.

Now, individual pages can provide their own title, description, canonical URL and other page-specific information while the common website infrastructure remains centralised. This became particularly useful during the migration itself. When I reviewed tracking and consent configuration, I didn’t need to make the same change across every page.

I Cleaned the URLs at the Same Time

Changing the architecture also created a good opportunity to improve some of the URLs. The old website used addresses such as:

/about.html /services.html /pricing.html /contact_us.html

The new website uses:

/about/ /services/ /pricing/ /contact/

But changing a URL on an existing website isn’t simply a matter of renaming something and moving on. Old URLs already exist in search engines, browser histories, external links or analytics data. So permanent redirects were added from the previous addresses to their replacements. The new structure could move forward without simply abandoning the old addresses.

The Migration Also Exposed Some Technical Debt

Once the website architecture started becoming cleaner, some older parts of the project became much more obvious. One example was the assets, the project had reached a point where CSS, JavaScript and images existed in duplicated asset locations. And unnecessary duplication creates an annoying question:

“Which one am I supposed to edit?”

After checking how Astro was building and serving the production website, the old duplicate asset directory was removed. That wasn’t necessarily the headline reason for moving to Astro. It was simply one of those improvements that became obvious once the rest of the project started becoming more organised.

The Blog and Main Website Finally Belong to the Same System

There was another slightly unusual situation before the migration, Client Flow Now blog was already using Astro. Meanwhile, main website was still largely traditional HTML.

So one project effectively contained two approaches. That was useful while introducing Astro gradually, but it wasn’t where I wanted the architecture to remain. The main business pages and the blog now share the same underlying component structure.

Navigation can be shared.
The footer can be shared.
Metadata handling can be shared.

The visual result is still the same website, but maintaining it is much more consistent.

Migrating the Pages Was Only Half the Job

Getting an Astro page to appear in a browser isn’t particularly difficult. The more important question was whether everything surrounding those pages still behaved correctly. Changing architecture on a live website can affect much more than what visitors see.

So after the pages were migrated, I checked:

Page routes
Canonical URLs
Page titles
Robots directives
Open Graph metadata
Blog URLs
Permanent redirects
Forms
Static assets
Privacy links
Sitemaps
PWA files
Service Worker behaviour
Error pages

The custom 404 page also needed to continue working correctly after deployment. This is the less visible side of a website migration.

A page looking correct doesn’t necessarily mean the migration is finished.

Preview First.

I also didn’t want the first proper test of the migration to happen on the live website. The completed branch was deployed to a separate preview environment, that allowed the new architecture to be tested before it reached the production branch.

I checked the new routes, the old redirects, blog articles, assets as well as PWA infrastructure. I checked that URLs which should remain indexable didn’t accidentally receive noindex.

Only after those tests passed was the migration merged into main and deployed to production. For me, that was probably one of the most important parts of the entire exercise.

A migration should have a rollback point.

“Let’s push it and see what happens” - isn’t much of a deployment strategy.

What Didn’t Change?

Astro didn’t suddenly make the website “better” simply because Astro appears in the repository. The existing HTML, CSS and JavaScript work wasn’t thrown away, design still looks like Client Flow Now.

The website remains heavily focused on delivering fast, lightweight pages. The forms still perform the same job, the concept websites continue to work as before, and the Progressive Web App (PWA) functionality remains in place.

The objective wasn’t to introduce new technology simply for the sake of using it. It was to reorganise a working website without unnecessarily disrupting the parts that were already doing their job well.

What surprised me, however, was how early the limitations of the original structure started to become noticeable. Client Flow Now is still a relatively small website, yet even at this stage, changes that should have been simple were beginning to involve multiple files, duplicated elements and more manual checking than they should.

That has also changed how I would approach the planning stage of a client project.

Even when a client says they need “just a website”, I would now spend more time considering what that website could realistically become before deciding on its architecture. Today it might be five pages and a contact form. A year later, the same business might want a blog, additional services, location pages, case studies, integrations or entirely new functionality.

That doesn’t mean every small website should be over-engineered from day one. Quite the opposite. The architecture should still match the actual requirements and budget of the project. But there is a difference between avoiding unnecessary complexity and building something with no room to evolve.

Sometimes “just a website” doesn’t stay just a website for very long.

For a visitor, the migration can feel almost invisible, for me working inside the project, it isn’t. None of those changes are particularly dramatic individually. Together, they change how comfortable the website will be to maintain as it continues to grow.

Of course, no major architectural migration would be complete without solving one of web development’s most demanding annual problems.

The Client Flow Now footer used to say:

Until 2027.

The year is now generated automatically in the visitor’s browser. So when the calendar moves to 2027, the footer will quietly become:

No deployment. No manual update. No emergency engineering meeting to discuss changing a 6 into a 7 on every single page just to keep the website looking fresh.

Years of web development experience finally put to good use. :-)

Was the Migration Worth It?

For the Client Flow Now website, yes. Not because Astro is automatically superior to static HTML. I covered that distinction in the previous article, and my view hasn’t changed.

A small business website with a handful of pages can still be an excellent candidate for straightforward HTML, CSS and JavaScript. But Client Flow Now isn’t intended to remain a handful of pages.

The blog is growing.
The concept library is growing.
More landing pages and industry-specific content are planned.
The website itself is becoming part of a larger platform.
The architecture now reflects that direction much better.

What Comes Next?

The migration wasn’t the destination. It was foundation work. Now that the main website and blog sit on a more consistent architecture, the interesting part is what can be built on top of it.

More content - maybe.
Better internal connections - for sure.
More reusable sections - 100%.
Industry-specific resources - probably.
New interactive features - if creativity allows.

And potentially much more sophisticated functionality later. The important thing is that we no longer need to solve those future requirements inside an architecture originally designed for a much smaller website.

The first version of Client Flow Now needed to work - and it did.
The next version needs to be easier to grow - and now it is.