I migrated my site from a self-hosted WordPress to Astro and wanted to talk about the process and reasoning to go through this migration.
Why migrate?
I’ve been using WordPress since its inception, and have used it for most of the websites I’ve worked on. While it’s a great tool and easy to use, I needed a change.
Another reason? Lowering costs. I host my blog (along with other websites) in a Siteground GoGeek plan. It costs around $600 each year. And while I’m certain there are other hosting providers that charge more for similar service, I couldn’t justify paying that amount for something I’m not using as much as I should be using it. Plus, website maintenance had become a real hassle with core updates, plugin updates and security vulnerabilities I had to be aware of.
With that in mind, I made it my goal to migrate or eliminate everything I have on my Siteground account before its next renewal which is July 4, 2026.
Why Astro?
Astro is a JS framework I really enjoy. I’ve tried other frameworks in the past but my preference has stuck with Astro. I already use it for my tech blog and haven’t had any issues.
Stack Comparison
WordPress
- Core / Language: PHP
- Database: MySQL
- Web Server: Nginx and Apache (hybrid structure)
- Caching/Speed: Siteground Optimizer
- Page Builder/Editing: Native Gutenberg Block Editor
- Forms: Gravity Forms
Astro
- Framework: Astro 6 for core templating and static site generation
- Content Management: Markdown/MDX
- CMS: Currently trying out GitCMS
- Styling: Using SCSS, may switch over to Tailwind (to be determined)
- Deployment: Vercel
WordPress Export to Astro
Thanks to the wordpress-export-to-markdown CLI tool, I was able to convert all my content from WordPress to functional Markdown files. Pages and Posts were converted to .md files. These files included essential and relevant frontmatter data (Post Title, Publication Date, Description/Excerpt, Categories, Tags, etc), making it easier for me to preserve a dynamic way of filtering and organizing the content.
The CLI tool is excellent, but if you use any custom shortcodes or implementations in your content body, there may be some cleaning up you have to do. For example: In WordPress, I used a custom shortcode for YouTube embedding that I had developed. Any posts that included that shortcode had to be cleaned up to use an equivalent or similar implementation for Astro.
Image Storage
One thing that worried me about this migration was image management and storage. My blog has content dating back to 2010, so I have a lot of images in the export. Since I’m now running this site using a Github repository, I didn’t want to add so much bloat to the repository with the images that could cause issues with future builds/deployments.
In my research, I found somebody that had a similar issue that used Cloudflare R2, a storage solution that offers a free plan for up to 10GB of storage. I ended up bulk migrating all my blog post images to this platform in a storage bucket and it is now serving all blog post images. Which reduces significant bloat to the repo.
Images associated with pages are still hosted internally since they are small in size and are about 10 or less in total.
Third-party tools
With WordPress, I had a specific set of tools to manage different needs.
Forms
With WordPress, I used Gravity Forms for anything form related. It’s a great tool that offers a lot of customization but it is exclusive to WordPress. When looking for alternatives for transactional email processing that could work for my scenario, two platforms stood out: Resend and Formspree.
I opted for Resend, mainly because they offer slightly more submissions/processing per month within the Free plan, which should fit my needs.
Comments
With WordPress, displaying and managing comments is very straight-forward since it’s a native feature. With Astro or other Static Site Generation platforms, it’s a bit more tricky. You need to find platforms that fit your scenario or build a custom solution.
During my research, there were about 5 solutions that I liked. Unfortunately, most of them required a monthly payment and/or complex configuration. In the spirit of avoiding additional costs, I ended up choosing Comentario, and am running this in a Railway instance that should remain free based on usage/resources. If it doesn’t, I’ll look for alternatives or a workaround.
Analytics
With Analytics, I am still using Google Analytics. This was easy to transfer as I just have to ‘move’ over the Google Analytics 4 measurement ID and apply it to my base layout.
Since this site is deployed on Vercel, I also enabled Vercel Analytics to have two sources to look at.
Result
I feel very accomplished to have made this happen over a weekend. There was a lot of learning gained from this, and I’m sure I’ll run into things that may need fixing or adjustments that I may not have noticed when running the initial deployments.
I’m still going through posts to migrate, so there will be more updates to the archive within the next two weeks.
—
If you have any questions about the migration process or anything explained in the blog post, please let me know by commenting below or send me a message through the contact form .
