TL;DR: I moved DigiNav from WordPress to Astro because a different foundation fit what I wanted the site to do and how I work. Before you change your own site's platform, look at its functions, the visitor's experience, and what you can update and maintain. Staying where you are may be the right decision for now.
What would change about the work?
I can still remember clear as day when I had the opportunity to work remotely. This was before 2000 when the internet connections still meant dial-up. The idea was intriguing and I was curious about all the ways that it would work. But the question started almost immediately as soon as I pictured me working from a home office.
Would I be able to keep up the work and hit my numbers? How would it be different without the office politics and giving people the feedback that they needed? Did I really want to work from my basement every day?
I weighed the pros and cons and realized that some of my concerns weren't really concerns at all. My husband worked for the phone company, so adding the dedicated line was possible. And I had the tech support close by. Plus I had room to create a secure office. The part I couldn't check off so easily was the work itself.
I had a flow. I would have to learn a completely new way to work and unlearn parts of the process that now came so easily.
But me being me, I decided to give it a try. We set up the office and added the phone line. Now it was time to connect online and get some work done. And I have to say at first it was painfully clunky. The system was slow, the server was even slower. We found that evenings worked better when the regular staff wasn't connected.
I also had to change how I entered information because of the way that the data moved and was saved. In the end, I made it work. And it actually was an enjoyable experience. And then we added two more people to join the remote work program. And even though the answers came not from a list of pros and cons, but actually how things were done, I had to see how the change would affect the work and then adjust when the first plan didn't meet the reality of my expectations.
✳︎ ✳︎ ✳︎
Hi, I’m Lee. Welcome to DigiNav Compass Signal. Around here, I share what happens when AI and technology meet a real business—the useful parts, the messy parts, and what you can take into your own work.
Today, I’ll be showing you how I decided whether DigiNav needed a different foundation, and the questions you can use to examine your own site before you make a plan.
✳︎ ✳︎ ✳︎
I could make WordPress work
This decision came back to me when I started looking at moving DigiNav from WordPress to a code-based site. Only this time, the pros and cons were completely different. When I first built websites, I used HTML, CSS, and other code. Whether I could hand-code a site wasn't the question. I started using WordPress because it was faster and easier to build. Over the years, I became really good at it. I built my processes around it, and I still run the WordPress agency today.
That was the first big factor in the decision. How would I be perceived as a WordPress agency if I moved DigiNav away from WordPress? I also wanted to ditch the database and make DigiNav more interactive and fluid. WordPress could do those things, but getting there wasn't necessarily easy. If I was going to custom-code the options anyway, why add another layer in between?
That's where the self-doubt came in. Some of it was removing the cape from the work I was doing with WordPress and putting on the cape of using code and AI to make the website. I also wondered whether I was making the move more complicated in my own mind because I was so familiar with WordPress and the processes I had built around it. I wasn't just choosing a new system. I would have to change the way I worked with it.
✳︎ ✳︎ ✳︎
Name the job before you ask about platforms
The first question was whether moving DigiNav off WordPress was a better option at all. WordPress could do much of what I wanted. I needed to look at what a move would make possible, what it would require, and whether staying would serve the work just as well.
For DigiNav, the useful starting point was specific: articles needed to work with the Waypoints, the visitor's path needed more interaction, and the content needed to be easy to find. Commerce could stay in ThriveCart. A simple form could handle basic collection. A content database was something to leave behind, not another system to maintain.
If you are weighing a move, try naming four things before you compare platforms:
What must keep working on the current site?
What do you want to make easier or add next?
What can stay in a service outside the site?
What will you have the time, skill, and support to update and maintain?
You can use an AI chat to help examine those answers. Here is a prompt to adapt, not one to follow word for word:
I am thinking about moving my website from [current platform]. First, ask me what the site must do now, what I may want it to do next, and what I do not want to maintain. Then compare staying where I am with up to two other ways to build it. For each option, explain what would have to move, how I would update the site, what I would maintain, and what could become harder. Use plain language. Do not choose a platform or make a build plan yet.Looking at the whole job—what the move would make possible, how I would move forward, and how I would update and maintain the site—helped me narrow the options to three. I compared their pros and cons from there, and Astro was the choice that made sense for DigiNav.
My coding and technical background helped me make sense of those choices. If you don't have that background, include it in what you ask AI. You can add a line like: “I don't code, and I'm not very technically savvy. Factor that into this decision too, including what I would need to learn or get help with to update and maintain the site.”
✳︎ ✳︎ ✳︎
The platform is one decision
A platform comparison shows what a new site can do. It cannot tell you what people will experience when they use it. If you are reworking a website, you need to check more than the framework:
Usability: Can someone find what they came for?
User interface (UI): Is it clear what they can do on each page?
User experience (UX): Does one step lead naturally to the next?
This was one of the biggest focal points for the DigiNav migration. I could have taken the WordPress site, converted it to Astro, and called it a day. But I didn't feel like users were getting as much out of the experience as they could. Once the framework question had an answer, it was time to address the user part of the work.
✳︎ ✳︎ ✳︎
Step one is to name the decisions
Before you make a migration plan, get clear on the decisions the plan will have to carry. For DigiNav, choosing a possible framework was only one part. The site also needed to work better for the people using it.
Here are the questions to address before you commit to a move:
Timing: Do you have room to give this decision the time it needs?
Platform: What does the current system make easy, and where does it add work? Would you stay with it or move to a different one? What would a new platform need to support?
Size of the move: Is this a brochure site—a small site that mainly tells people what you do and how to contact you? That usually leaves fewer decisions to make. A site with a store, membership, or custom functions has more to account for before you choose how to move it.
Functionality: What must keep working? What new functions will the site need, and what can live in a service outside it?
Visitor experience: Where do people get stuck? What should be easier to find, understand, or do? If you want more interaction, what job will that interaction serve?
Accessibility: How will people use the site with a keyboard, a screen reader, or on a small screen? How will you check that the move protects access?
Care after launch: Who will update the content, maintain the site, and fix what breaks? What time, knowledge, and help will that take?
✳︎ ✳︎ ✳︎
Staying where you are may be the better choice for now if you cannot give the decision enough time, you are in the middle of a business pivot, or your site has functions that need more thought before you move them. You may also need time to learn the tools you would use to build and maintain a new site. Just check whether that is a real limit or whether fear of the unfamiliar is making the decision for you.
By the end of this first phase, I had made the decision to move DigiNav off WordPress and build it with Astro. I still get that queasy feeling that I’m abandoning WordPress, even though I still run a WordPress agency. Both things can be true: WordPress still serves my clients, and DigiNav needs a different foundation for what I want to build.
My coding background helped me judge the options. I also knew I could use AI to help with much of the build, which would give me more room to focus on how DigiNav grows and how people use the site. The first small changes have been easy to make. How the site holds up as it grows is something I’ll keep checking.
That was the outcome of phase one: a decision with a clear reason behind it. In the next article, we’ll look at how the site’s needs led to the technical choices, including Astro.