Thinking of Migrating to Squarespace? Read This First
This is the guide I wish existed when my clients first came to me. It's written for business owners, creatives, and solo practitioners who are considering moving their website to Squarespace and who want to understand the full picture before they begin.
The problem with not owning your own website
I’ve been a faithful user of Squarespace for over 10 years now (10 years!) and have been designing and building sites for almost the same amount of time. One of the most common types of clients I meet is a business owner, NGO founder, team lead or solo entrepreneur who has been considering making a move from an alternative platform (most often Wordpress, sometimes Wix or Weebly) to Squarespace. The reasons for migrating over tend to follow a similar thought process:
I don’t have enough direct access to my site: It was built by an agency, and every time I want to make an update, I have to contact them, wait for the update, and manage the back and forth process. By the time this happens, things in my business have changed. As a result I often don’t end up making any updates at all, or put them off indefinitely to the point where my site has become static and outdated.
I feel overwhelmed by the interface: I don’t know where to find anything, the back-end feels overly complicated, and although it has been explained to me numerous times, I struggle to ‘get it’ and end up not using my site at all. When I do log in and attempt to make changes I’m afraid of ‘breaking’ something in the design or set up!
I am stressed out by the number of plugins that seem to be required on the site: security plugins, SEO plugins, form plugins, and all manner of other plugins. Each of them costs time, effort, understanding and money to maintain, and I feel like I’m paying a lot of money in addition to the cost of the site hosting, domain hosting and all the other add-ons.
I no longer love the design of my site: both on the front end (how it appears on desktop, mobile and other devices) and on the back end (when I log in to make updates and changes). I want something that feels more calming for my nervous system, more streamlined and simple, and that is a more enjoyable user experience.
I don’t love the feeling of not really owning my own website: I wish I had more direct access to the content, the updates, the process - from how it looks, the images and text, updating events, products in my shop, sending newsletters, or simply alerting my readership, clients, customers and followers to what is happening in real time.
Most of the clients who come to me for a website migration have one thing in common: somewhere along the way, they lost ownership of their own digital presence, and a move toSquarespace provides an opportunity to really take back that ownership.
Why Squarespace?
When I started using Squarespace back in the day, it really offered only one solution: a self-hosted website with simple, minimal design features. You paid your subscription, started from one of their classic 7.0 templates and that was it.
A fully functioning ecosystem
Since then, Squarespace has evolved to become a fully functioning ecosystem of digital offerings which include and are not limited to:
Domain management (the URL for your online home)
Hosting (making sure your site content is live online)
Email campaigns (making sending newsletters + updates simple)
Event management (host and manage events within your site)
Online store (list physical, digital and other products and get paid for them)
Scheduling (book client meetings with Acuity/Scheduling)
Membership (develop a paid/closed member site right within Squarespace)
Teaching and learning (host video, audio and other content behind a paywall)
Professional email (their partnership with Google Workspace makes setting up email simple)
Invoicing + project management (manage your client communications from within the system)
Donations (accept payments and donations right from your site)
There are more products being developed and added all the time. But in essence, Squarespace is a self-hosted web-building platform that allows you to start small, develop as you go, and grow your online presence alongside your business. In addition to this all-in-one nature of the environment, the design philosophy is also very appealing.
Design philosophy of simplicity
Calm front-end design: more negative space, fewer design choices (fonts, buttons, colours, layouts), just enough features to choose from (galleries, forms, sections, lists, summaries etc)
Simple back-end experience: built for the business owner not a developer. It is easy to find what you’re looking for, there isn’t an overwhelming amount of menus, options and tabs.
Baked-in features vs external plugins: what you see is what you get, there are few standard features that come with your subscription, and that’s it. For some people this feels limiting, but in my experience, for most clients it brings a sense of calm and clarity. There are enough tools for what they require, and not an endless list of options to get distracted by.
Award winning customer service, suppport + help options
As part of your Squarespace subscription, you get access to a 24/7 helpline either via an email ticketing system or via a messaging chatline. There are a ton of excellent resources on every topic Squarespace has to offer from billing to hosting, and from commerce to payments. Learn at your own pace, find the information you need when you need it via the support site.
Price point
The price point is competitive. Starting from US$18/month (paid annually) you get access to a self-hosted website that works for where you’re at now, with space to grow and expand.
You own it
Many clients coming from an agency-managed WordPress site share some version of the following sentiment: "I feel like it's not really my website." And in a very real sense, they're right. Although having a third party hold your logins, manage your hosting, and understand the back end of your site can feel safe (‘At least I can’t break anything’ and ‘The experts know what they’re doing!’), this dynamic may also mean that when it comes to having a real say in your website management, you become a tenant in your own digital home.
Squarespace flips that dynamic entirely. Your site, your login, your content managed by you, on your terms, in your own time. No waiting for an agency to action your updates, no monthly retainer for changes you could make yourself in minutes. That sense of direct ownership, once you have it, is hard to give up.
SEO built in
One of the most common concerns I hear from clients considering a move away from WordPress is: "But what about my SEO? I use Yoast." It's a fair question. Yoast has become so synonymous with SEO management on WordPress that many people assume they'll be losing something significant by leaving it behind. The good news is that Squarespace has robust SEO features built directly into the platform with no plugin required. Page titles, meta descriptions, clean URL structures are all accessible from within your page settings. It's not buried in a separate plugin dashboard or hidden behind a premium upgrade. For the vast majority of small business owners, it covers everything you actually need and the cleaner, faster-loading templates that Squarespace is known for are themselves an SEO advantage that often gets overlooked.
What a migration actually involves
If you’re thinking about making the move from WordPress, Weebly, Wix (or something else) to Squarespace, what does a migration actually involve? Get ready because this is a lot of information to take in. But if you’re anything like me I like to have all the information on hand before I start.
A site migration is the process of moving your website from one platform or hosting environment to another.
That means taking your existing web presence: your pages, your content, your images, your blog posts, your shop with their products and rebuilding it on Squarespace. I use the word rebuilding deliberately, because this is an important distinction: migrating to Squarespace is not a direct copy-paste of your existing site, or an export here and import over there process. It is a rebuild, informed by your existing content, but designed fresh on a new platform.
This surprises some people. There is a reasonable assumption that a migration is more like moving house: you pack everything up and it arrives intact on the other side. In reality it's closer to moving neighbourhood and taking the things that matter with you, while leaving behind what no longer serves you. For many clients, the migration becomes an opportunity to audit what's actually on the site, cut what's outdated, refresh what's stale, and arrive on the other side with something leaner and more intentional than what they started with. More on that later.
Elements involved in a migration
Let's break down the different elements involved in a migration, because understanding the full picture upfront is one of the best things you can do to set yourself, and the process, up for success.
A site migration is rarely just about the website itself. It touches your domain, your email, your hosting, your DNS settings, and sometimes third party services you may have forgotten were even connected to your site. Each of these elements has its own logic, its own timeline, and its own potential for delay if not handled carefully and in the right sequence. None of it is beyond understanding, but it does require a willingness to get familiar with a few concepts that may be new to you.
Think of this section as your orientation. We're not going to go deep into the technical weeds, but we are going to make sure you know what everything is, why it matters, and what role it plays in getting your new site live.
When someone comes to me with a request for a site migration, here are all the elements I expect we will work on during the project along with questions I will ask them:
1. Domain: What is your current domain? Do you have more than one?
2. Domain provider: Which domain provider currently hosts your domain? A domain provider or registrar (such as GoDaddy, Hover, BlueHost, Namecheap, Xneelo, Afrihost, One.com etc.) is a company where your domain name is registered and managed.
3. Domain access: Who currently has access to your domain, with a login and password and can access the settings within your domain profile? This may be you, a contact within a design agency, or an IT specialist.
4. Domain options: Do you plan to keep your current domain hosting* (also known as domain pointing), or do you plan to transfer your domain away from your current hosting to have it managed by Squarespace?**
A NOTE ON DOMAIN POINTING VS DOMAIN TRANSFERRING
When it comes to connecting your existing domain to your new Squarespace site, there are two routes available to you, and it's worth understanding the difference before you decide which one is right for your situation.
Pointing your domain means you keep your domain registered with your current provider (domains.co.za, GoDaddy, Namecheap, or whoever you're currently with) but you update the DNS settings within that account to direct your domain to your new Squarespace site. Think of it like keeping your postal address registered at the post office but redirecting all your mail to a new physical location. Your domain stays where it is, but the internet now knows to send visitors to your Squarespace site instead. This is the most common approach for migrations, and in most cases it's the simplest and least disruptive option.
Transferring your domain means moving the domain registration itself from your current provider over to Squarespace, so that everything (your website, your domain, and potentially your email) lives under one roof. This can be a tidy long-term solution, particularly if simplicity and having fewer logins and accounts to manage appeals to you. However there are some important limitations to be aware of:
Domains that have been registered or transferred within the last 60 days are locked and cannot be transferred: this is an ICANN rule that applies universally, not something any individual provider can override
The transfer process itself can take anywhere from 5 to 7 days to complete, sometimes longer, and requires action on your part to approve the transfer via email
During a transfer there is a small window of potential disruption, which is why timing matters
Some country-specific domain extensions (like .co.za) have their own additional transfer rules and processes that differ from standard .com transfers
So which option is right for you? For most clients I work with, particularly those with a .co.za domain or a domain registered relatively recently, pointing rather than transferring is the recommended starting point. It's faster, lower risk, and achieves the same end result — your new Squarespace site is live and your domain works correctly. A transfer can always be done later, once everything is settled and live, if you decide you'd like to consolidate everything under Squarespace.
5. Email: Do you currently have an email address associated with your domain name and will migration of your site affect your email functioning?
6. Email management: Who currently manages your email? And how do you plan to make sure your email services are not interrupted during the migration process*
A Note on Email: What You Need to Know Before We Start
Email is one of the most overlooked aspects of a site migration and one of the most important to get right. Unlike your website, which can afford a brief window of being unavailable while things are being set up, email disruption can have immediate and real consequences for your business. Before we begin, it's worth understanding which of the following scenarios applies to you.
Scenario 1: You use a free Gmail, Yahoo, or other personal email account
If your business email is something like yourname@gmail.com and it has no connection to your domain or your website, you have nothing to worry about. Email carries on completely unaffected by the migration. Nothing needs to change.
Scenario 2: Your email is set up through your current hosting provider or agency
This is where things get more complex. If your email address is something like hello@yourbusiness.com and it was set up by the same agency or hosting company that manages your website, then your email and your website are likely sharing infrastructure. In this scenario the migration needs to be carefully coordinated to make sure email is not disrupted when the domain is pointed to Squarespace. This is something we need to discuss and plan for before we touch anything.
Scenario 3: You use Google Workspace or Microsoft 365
Google Workspace and Microsoft 365 are standalone email systems that are associated with your domain but operate independently of your website hosting. This is actually the tidiest scenario but it does require that specific DNS records called MX records are correctly in place when your domain is pointed to Squarespace. If these records are missing or incorrectly configured, your email will stop working even though your website is live. This needs to be checked and confirmed as part of the migration process.
Scenario 4: Your email is set up on devices via a mail client like Outlook or Apple Mail
If you or your team access email through a mail client on a laptop, desktop, or phone, any changes to your email setup may require those devices to be reconfigured. This falls firmly outside the scope of a website migration and is something your IT support person or email provider will need to assist with. Which brings me to an important point.
If you don't currently have an IT person or support contact for this, it's worth identifying one before we begin, particularly if email continuity is critical to your day to day operations.
6. DNS Records: DNS (Domain Name System) records are the behind-the-scenes settings that tell the internet where to find your website, where to deliver your email, and how to verify that your domain belongs to you, and because these settings are stored across thousands of servers worldwide, any changes you make can take anywhere from a few hours to 48 hours to take full effect globally, a process known as propagation. DNS records need to be edited/amended in this migration process so it’s important to have access to editing them, usually within your account via the domain provider’s interface.
7. Your Current Website Platform: Knowing what platform your site is currently built on, whether that's WordPress, Wix, Weebly, or something else, and who currently has login access to that account is essential groundwork, because in some cases your current platform, your domain, and your email are all managed under one login by one agency, and unpicking those dependencies carefully is what prevents things from going wrong during the transition. Typically, during the process of migration, I will also need access to your current website platform to see behind the scenes how the site was set up in order to have all the information I need to set up the new site.
8. Current Hosting: Your website hosting is the service that stores your site's files and makes them accessible on the internet, and it's worth establishing upfront whether your hosting is managed separately from your domain because in many cases, particularly with WordPress sites, clients discover that their domain, hosting, and email are all bundled together under one provider or agency, which has direct implications for how and in what order we approach the migration.
A note on self-hosted vs hosted platforms:
A self-hosted site (which is what most WordPress sites are) means that your website software and your website hosting are two separate things: WordPress itself is free to install, but you are responsible for renting your own server space from a hosting provider, keeping the software and plugins updated, managing security, and either doing all of that yourself or paying an agency or developer to do it on your behalf.
A hosted platform like Squarespace, by contrast, bundles all of that together (the software, the hosting, the security, the updates) into a single monthly or annual subscription, which is a large part of why the switch feels so liberating to people who have spent years managing (or paying to manage) all of those moving parts separately.
It's also worth noting that WordPress.com and WordPress.org are two entirely different things. WordPress.com is a hosted platform similar to Squarespace, while WordPress.org is the self-hosted software that most agency-built WordPress sites run on, a distinction that confuses almost everyone encountering it for the first time.
9. Third Party Services: One of the most overlooked aspects of a migration is the number of third party services that can be connected to your domain or your current website, sometimes visibly, sometimes completely behind the scenes, and identifying these early prevents potential osurprises when the new site goes live.
COMMON THIRD PARTY SERVICES TO CHECK FOR INCLUDE:
Domain & Security
Cloudflare (DNS management and security layer: often added by agencies without the client's full awareness)
SSL certificate providers (usually handled automatically on Squarespace, but worth noting if currently managed separately)
Analytics & Marketing
Google Analytics
Google Search Console (your domain will need to be reverified after migration)
Meta Pixel (Facebook/Instagram tracking)
Mailchimp, Flodesk, Kit or other email marketing platforms
Google Tag Manager
Booking & Scheduling
Acuity Scheduling (now owned by Squarespace — integrates natively)
Calendly
SimplyBook.me
Fresha (popular with wellness and beauty clients)
Mindbody (common with pilates studios, yoga studios, fitness instructors)
Payment & Ecommerce
PayPal
Stripe
PayFast (South Africa specific)
Yoco (increasingly popular with SA small businesses)
WooCommerce (WordPress specific)
Accommodation & Listings
Airbnb (profile links rather than integrations, but worth checking)
Booking.com
Nightsbridge (popular SA accommodation booking system)
direct booking widgets or channel managers embedded in the current site
Social & Community
Social login buttons (Facebook login, Google login)
Instagram feed integrations
Pinterest save buttons
Embedded YouTube or Vimeo channels
Podcast players (Spotify, Apple Podcasts embeds)
Creative & Portfolio Specific
Behance or Adobe Portfolio links
Printful or other print-on-demand integrations (photographers, designers)
Font or typeface licensing that may be platform specific
Digital download delivery services
Other
Google Business Profile (linked to your domain and needs to be checked post migration)
WhatsApp Business (if linked via click-to-chat on the site)
Live chat widgets (Tidio, Intercom etc.)
Pop-up or lead capture tools (Sumo, OptinMonster etc)
Affiliate or referral tracking links
A note on code blocks and embeds:
Many WordPress, Wix, and Weebly sites make use of custom code blocks or embed codes — small snippets of code that have been inserted into the site to add functionality that the platform doesn't natively support. These might include booking widgets, map embeds, custom contact forms, chat tools, payment buttons, or third party portfolio displays. Squarespace does support custom code blocks and embeds, but they need to be identified on your current site, sourced fresh from the relevant third party service, and reinserted manually on the new site. They do not carry across automatically in a migration, and in some cases a native Squarespace integration or plugin may exist that does the same job more cleanly than a code embed. It's worth flagging any functionality on your current site that feels "custom" or was added by a developer, so we can assess the best approach for replicating it on Squarespace.
10. Content Inventory: What content is coming across to the new site such as pages, images, blog posts, products, documents?
Before any design or build work begins on your new Squarespace site, it's worth taking stock of exactly what content exists on your current site and making a deliberate decision about what is coming across, what is being updated, and what is being left behind entirely.
This is one of the most time-consuming parts of a migration, but it is also one of the most valuable. A migration is a natural audit of your digital presence, and most clients are surprised by how much outdated, irrelevant, or simply forgotten content has accumulated on their site over the years. Approaching the content inventory with fresh eyes, rather than treating it as a box-ticking exercise, tends to result in a new site that is leaner, more focused, and more reflective of where the business actually is today.
CONTENT TO WORK THROUGH INCLUDES:
Pages
Which pages are coming across to the new site?
Are any pages outdated, redundant, or no longer relevant to your current offering?
Are there pages that need to be written from scratch or substantially rewritten?
Are there new pages that don't exist on the current site that need to be created?
Images
Do you have access to your original high resolution images, or are they only accessible via the current site?
Are the images on your current site still current and reflective of your brand?
Do any images need to be replaced, updated, or supplemented with new photography?
Are there any images on the current site that belong to a photographer or agency and may have licensing implications?
Blog Posts
How many blog posts exist on the current site?
Are they all coming across, or only a selection?
Are older posts still relevant and worth migrating, or would a fresh start serve you better?
Note that blog posts do not migrate automatically: each post needs to be manually recreated on Squarespace, which has time implications for the project
Products
If you have an online shop, how many products are currently listed?
Do product descriptions, pricing, and images all need to come across, or is this an opportunity to refresh and rationalise the product range?
Note that product data does not transfer automatically and needs to be rebuilt on Squarespace
Documents and Downloads
Are there any PDFs, price lists, brochures, menus, or downloadable resources on the current site that need to come across?
Do any of these documents need to be updated before being republished on the new site?
Video and Audio
Is there any video content embedded from YouTube or Vimeo that needs to be accounted for?
Are there podcast episodes or audio files hosted on or linked from the current site?
Forms
What contact forms, enquiry forms, or booking forms exist on the current site?
What happens to the data submitted via those forms: where does it go and does that need to be replicated?
A word on content responsibility:
Providing content - whether that means supplying text, images, documents, or decisions about what stays and what goes - is the your responsibility, not the designer's. Delays in content delivery are one of the most common reasons a migration takes longer than expected. The earlier you can work through this list, the smoother the build process will be.
12. SSL Certificate: An SSL certificate is what puts the padlock in your browser address bar and the "s" in https. It tells visitors that your site is secure and their connection is encrypted. On Squarespace this is issued and managed automatically once your domain is correctly pointed and your DNS has propagated, so it's not something you need to purchase, install, or think about, it just happens.
13. Go-Live Timeline: Of all the elements involved in a migration, timeline is the one that catches people out most often, and in my experience, it is almost always underestimated. The build of your new Squarespace site and the technical process of making it live are two separate things that need to be carefully sequenced, and the domain pointing, DNS propagation, email continuity, and SSL certificate cannot be rushed.
Here is the order in which things typically need to happen:
The new site is built and ready,
Domain access is confirmed,
DNS records are prepared,
DNS changes are made,
Propagation window (a few hours to 48 hours),
SSL certificate is issued
14. Post-Launch: Going live is not the finish line! Once your new Squarespace site is up and running there are a handful of important housekeeping tasks to attend to, including setting up redirects for any old URLs that may have changed (so that existing links and search engine results don't lead to dead pages), reverifying your domain in Google Search Console, and checking that any third party platforms, integrations, and connected services are correctly pointing to your new site.
15. Site Management: One of the most important, and most often undiscussed, questions at the start of a migration is who will actually be responsible for managing the site once it is live. This is the moment to make a conscious decision about whether you are moving to a self-managed model, where you take direct ownership of updates, content changes, and day to day management, or whether you intend to continue working with a designer or agency on an ongoing basis, because the answer to that question has implications for how the site is built, how it is handed over, and what training or documentation you might need to feel confident managing it yourself.
A good time to pause and consider a (site) redesign
Here's something that happens almost every time.
You've been head-down in your business. Your website has been ticking along in the background managed by an agency, or simply left alone because it was too complicated or too time-consuming to deal with.
Out of sight, out of mind.
Then the migration process begins, and suddenly you're looking at everything at once: every page, every image, every line of copy. And a feeling creeps in that's hard to ignore.
This feels old.
The fonts feel dated. The colours no longer feel like you. The homepage hero image is from a photoshoot three years ago. The about page describes a version of your business that has since evolved into something quite different. The whole thing feels like a coat you've outgrown.
This is completely normal, and it happens to almost every client I work with. A migration is one of the rare moments when your entire digital presence is on the table at once and that visibility has a way of surfacing things that have been quietly bothering you for longer than you'd like to admit.
So before the build begins, it's worth pausing and asking: do I just want to migrate, or do I also want to redesign?
Migration vs redesign: What's the difference?
A migration and a redesign are related but distinct.
A migration is about moving. Taking your existing site and rebuilding it on a new platform. The focus is on replicating and transferring: your pages, your content, your structure, your functionality. Done well, a migration results in a site that looks and works like your current site, but lives on Squarespace.
A redesign is about reimagining. Reconsidering how the site looks, feels, and functions from the ground up. It touches your layout and page structure, your typography and colour palette, your imagery and visual style, your graphic elements and animations, and the overall user experience of moving through the site. A redesign asks not just what do we have but what do we actually need, and how should it look and feel?
What does a redesign actually involve?
A redesign can touch any or all of the following:
Layout and page structure: how pages are organised, what sections appear and in what order, how the user moves through the site
Typography: your font choices, sizing, and hierarchy
Colour palette: your primary, secondary, and accent colours
Imagery: the style, tone, and quality of photography and graphics used throughout the site
Graphic elements: icons, dividers, textures, patterns, illustrations, and decorative details
Animation and movement: scroll effects, hover states, transitions
Mobile experience: how all of the above translates across devices
Copywriting: the tone, length, and structure of your written content
Not all of these need to change. A redesign can be as light or as thorough as the brief requires. but it's worth knowing which elements are in play from the start.
Redesign vs brand refresh: are they the same thing?
Not quite, though they often overlap.
A site redesign is specific to your website. It's about how your digital presence looks and functions online.
A brand refresh goes deeper. It revisits the underlying visual identity that informs everything: your logo, your colour palette, your typography system, your tone of voice, your overall aesthetic. A brand refresh asks whether the brand itself still reflects who you are and where you're going, and the answers to those questions then inform the redesign.
Sometimes a migration prompts a site redesign, which in turn surfaces the realisation that a brand refresh is overdue. This added layer of clarity means a longer timeline, a broader brief, and a different conversation about budget and process. The important thing is to identify this early, not halfway through a site build.
If you find yourself looking at your logo and feeling the same ergh you felt looking at your homepage, that's probably worth paying attention to.
Why now is actually the right time for a redesign (or rebrand)
There is never a perfect time to redesign your site. There is always something more pressing, a season that's too busy, a budget that needs to settle. But a migration creates a natural window:
The site is already being rebuilt,
the content is already being reviewed,
the design decisions are already being made.
Addressing the redesign now, as part of the migration, is almost always more efficient and more cost-effective than migrating first and redesigning six months later.
How to choose the right person to work with for a site migration
The right person for this job is not necessarily the most technical person you can find. It's the person who can hold the technical complexity so that you don't have to.
This is a subtle but important distinction. A site migration touches domains, DNS records, email configuration, platform settings, content, design, and third party integrations (and possibly more) and the person guiding you through it needs to have a working knowledge of all of those things. But working knowledge is different from deep expertise in every area. What matters more than knowing everything is knowing enough to keep things moving, knowing when something is outside their lane, and knowing how to direct you to the right resource when it is.
There are broadly two types of wrong choices when it comes to hiring for a project like this, and they sit at opposite ends of the spectrum.
The first is the overtechnical person: someone who can build almost anything but communicates entirely in jargon, makes you feel slightly stupid for not knowing what a CNAME record is, takes over rather than guides, and leaves you at the end of the project just as dependent on an external person or agency as you were before. You've migrated platforms but you haven't actually changed anything about your relationship with your own site. That, in my opinion, is not a win.
The second is the underprepared person: someone who can make a Squarespace site look genuinely beautiful but has never had to navigate a DNS propagation issue, goes quiet when the domain doesn't point correctly, and isn't quite sure what to do when the previous agency stops responding. Their design skills are real, but the migration-specific knowledge isn't there, and you'll feel that gap at exactly the wrong moment.
The right person sits between those two. Technically grounded enough to handle complexity without panicking. People-focused enough to bring you along with them rather than leaving you behind.
What to look for in someone to guide you through a site migration
1. Relevant experience
There is a difference between someone who builds Squarespace sites and someone who has managed migrations to Squarespace. The skills overlap but they are not the same. Ask specifically whether they have experience with migrations (from WordPress, Wix, or Weebly) and whether they have handled the domain and DNS side of things themselves or whether they have always handed that off to someone else.
2. A portfolio that reflects your world
Look at who they have worked with and whether any of those clients resemble you in industry, in business size, in the kind of site they needed. A designer who has worked extensively with small businesses, solo practitioners, creatives, and NGOs will understand your context in a way that someone whose portfolio is all large corporate sites may not.
3. Testimonials from non-technical people
If their testimonials are all from other designers or developers, that tells you something. If their testimonials are from business owners, therapists, photographers, and small NGOs saying things like "she explained everything so clearly" and "I actually feel confident managing my site now" that tells you something quite different, and more relevant.
4. Clarity on scope
The right person will be very clear, early, and in writing, about what they do and do not cover for example email migration, IT support, Google Workspace setup, ongoing domain management etc. These may or may not be part of the service, but there should be no ambiguity about it. Vagueness around scope at the start of a project has a way of becoming tension and disappointment by the end of it.
5. Honest, realistic timelines
Be cautious of anyone who makes the process sound simpler or faster than it is. A migration has moving parts that cannot be rushed. DNS propagation alone can take up to 48 hours and no amount of urgency changes that. The right person will give you a realistic picture of the timeline upfront, build in buffer for the unexpected, and advise you clearly on when things need to happen and in what order. Overpromising at the start is a red flag.
6. How they handle things going wrong
Something almost always does. A DNS record that won't propagate, a previous agency that goes quiet, a domain that turns out to be locked. The question is not whether complications arise, it's how the person you're working with responds when they do. Do they communicate proactively, stay calm, and keep moving forward? Or do they go quiet, get flustered, or start pointing fingers? This is hard to assess before a project begins, but asking directly "what happens if the go-live is delayed or something unexpected comes up?" can tell you a lot about how someone operates under pressure.
7. They ask good questions before they talk about design
A designer who jumps straight into talking about what they'd build you, without first asking about your business, your audience, your goals, and your content, is a red flag. The right person will want to understand what you actually need before they start proposing solutions. They'll ask about your current platform, your domain setup, your email, your timeline, your budget, and what success looks like to you. That curiosity is a good sign.
8. Chemistry and communication
This one is underrated and rarely talked about, but it matters enormously. You are going to be in close, sometimes daily communication with this person during what can be a stressful and technically complicated process.
Do you feel comfortable asking what might feel like a stupid question?
Do they explain things in plain language without making you feel patronised?
Do you feel at ease in their company or slightly on the back foot?
Trust your gut. A technically brilliant person you feel uncomfortable communicating with is a much harder working relationship than a slightly less technical person you can talk to openly and honestly.
The thing that matters most
Ultimately, the most important quality to look for is this: does this person's goal seem to be to leave you more capable and more confident at the end of the project than you were at the beginning?
The reason you're doing this migration in the first place, the reason this whole post exists, is that somewhere along the way you lost real ownership of your digital presence. Someone else held the logins, managed the complexity, and became middleman between you and your own website. The right person to work with on a migration is someone who actively works against that dynamic. Someone who explains rather than mystifies, who teaches rather than gatekeeps, who builds the site with you in a way that means you can actually run it confidently when they're done.
You're not just looking for someone to build you a website. You're looking for someone who hands it back to you.
What to expect from the process of working together
One of the things that makes commissioning a website feel daunting, particularly if you've only ever dealt with agencies, or have never commissioned one before, is not knowing what the process actually looks like.
What happens first?
What will be asked of you, and when?
How long does each stage take?
What does it feel like from the inside?
What follows is a practical walkthrough of how a typical migration project unfolds, from the first conversation to the moment your new site goes live. Every project is different, and timelines vary depending on scope, complexity, and how quickly content and decisions come together, but the broad shape of the process tends to follow the same arc.
1. First enquiry and discovery call
It usually starts with an email or a contact form submission: a brief introduction, a sense of what you're looking for, and a question about whether you're available and whether it might be a good fit. From there, a discovery call is usually the next step.
A discovery call is not a sales pitch. It's a conversation, a chance for both sides to get a feel for each other, ask questions, and establish whether working together makes sense. Expect to be asked about your current platform, your domain setup, your email situation, your timeline, your budget, and what you're hoping the new site will do for you and your business. The more honest and specific you can be at this stage, the more accurate and useful the proposal that follows will be.
This is also your opportunity to ask questions. What is their experience with migrations? How do they handle the domain and DNS side of things? What do they need from you and when? What does their timeline look like? A good discovery call leaves both parties with a clear enough picture to decide whether to move forward.
2. Quote and contract (or proposal and agreement)
Following the discovery call, a quote is usually prepared outlining the scope of the project, what is and isn't included, the timeline, the investment, and the payment terms. Read this carefully. This is the document that defines the boundaries of the project: what you're getting, what you're not getting, and what happens if the scope changes.
A few things to look for in a quote:
Is the scope clearly defined, including what is explicitly excluded?
Are the payment terms clear: deposit upfront, balance on completion, or staged payments?
Is there a clear revision policy: how many rounds of revisions are included, and what happens if you need more?
Is there a clear go-live process outlined?
Once the proposal is agreed and the deposit is paid, the project officially begins.
3. Content collection
This stage is the one that most often causes delays, and it is entirely in your hands. Before design and build work can begin in earnest, the content for the new site needs to be gathered, organised, and supplied. This includes your written copy, your images, your logo files, any documents or downloads, and decisions about what is coming across from the old site and what is being left behind.
If your content needs to be written from scratch, or if existing copy needs significant updating, now is the time to address that, either by writing it yourself or by bringing in a copywriter. Similarly, if your photography is outdated or no longer reflective of your brand, this is the stage at which to organise a shoot or source new imagery. Waiting until the site is half-built to address content gaps creates delays, pressure, and sometimes compromises in the final result.
The single most useful thing you can do to keep a project on track is to treat content collection as a priority from day one, not something to get to when you have a moment.
4. Design and build
Once content is in hand, or at least substantially in hand, the design and build phase begins. On a Squarespace migration this typically involves:
Setting up the new Squarespace account and selecting or building the appropriate template foundation
Establishing the design system: fonts, colours, spacing, graphic elements in line with your brand
Building out each page, importing and formatting content, and integrating any third party services
Optimising for mobile across all pages
Setting up SEO basics: page titles, meta descriptions, URL structures, image alt text
Internal testing and quality checking before anything is shared with you for review
You will usually be given access to a preview of the site, either via a password-protected Squarespace URL or a screen share session, once a substantial draft is ready. This is not the finished product. It is a working draft, and it is normal for it to feel incomplete or imperfect at this stage.
5. Review and revisions
Once the draft site is shared with you, a review period begins. This is your opportunity to go through the site thoroughly on desktop and on mobile and compile your feedback. A few suggestions for making this stage as smooth as possible:
Go through the site as your ideal client would: start at the homepage and move through it as a visitor, rather than jumping between pages at random
Note anything that feels unclear, incorrect, or not quite right: copy errors, image choices, layout issues, missing content
Consolidate your feedback into a single document or communication rather than sending it in multiple messages over several days
Be as specific as possible: "the font on the about page heading feels too large on mobile" is more useful than "something feels off"
Most projects include a defined number of revision rounds (typically two) so it's worth being thorough in your review rather than sending feedback in instalments.
6. Pre-launch preparation
Once revisions are complete and the site is signed off, attention turns to the technical preparation for go-live. This is the stage that requires the most coordination and the most careful timing. It involves:
Confirming domain access and login credentials for your domain provider
Preparing the DNS records that need to be updated
Confirming that email is accounted for and that MX records are in place
Identifying any third party services that need to be reconnected post-launch
Agreeing on a go-live date and time: ideally a Monday or Tuesday morning, with buffer days available if needed
Nothing should be rushed at this stage. If the domain access isn't confirmed, if there's uncertainty about the email setup, or if a previously unknown complication surfaces, it is always better to pause and resolve it than to push ahead and deal with the consequences on a live site.
7. Go-live
Go-live day is the moment the DNS records are updated and your new Squarespace site begins to replace your old one on your domain. As covered earlier in this post, this is not an instantaneous switch, it is a propagation window of anywhere from a few hours to 48 hours during which the change rolls out across the internet.
During this window it is normal to see the old site in some browsers or locations and the new site in others. This is temporary. The best thing you can do during this period is stay calm, avoid making further changes to either site, and keep in close communication with your designer.
Once propagation is complete and the SSL certificate has been issued, the new site is fully live. Take a moment to celebrate. You’ve done it!
8. Post-launch
Going live is not the finish line. In the days immediately following launch, a number of post-launch tasks need to be attended to:
A thorough check of all pages, links, forms, and integrations on the live site
Setting up URL redirects for any pages whose addresses have changed, so that existing links and search results don't lead to dead pages
Reverifying your domain in Google Search Console
Checking that email is working correctly across all devices and accounts
Confirming that any third party integrations: booking systems, payment gateways, email marketing platforms etc. are correctly connected and functioning
9. Handover and independence
The final stage, and in many ways the most important one, is handover. This is where you take the wheel.
A good handover includes a walkthrough of the Squarespace backend so you know where everything lives and how to make the most common updates yourself:
editing text,
swapping images,
adding a blog post,
updating your shop.
It may also include a short recorded walkthrough you can refer back to, written documentation for anything recurring or complex, and clarity on what to do if something goes wrong or you get stuck.
The goal of a good handover is simple: you should finish it feeling capable, not dependent. The site is yours. You should feel like it.
What it actually costs
This is usually one of the first questions people ask, and it's also one of the hardest to answer without knowing the specifics of your project. A site migration is not a fixed-price, off-the-shelf service: the scope, complexity, and time involved vary enormously from one project to the next, and a quote that's right for a five page portfolio site will look very different from one for a thirty page WordPress site with a blog archive, a shop, and four third party integrations.
What I can do is give you a clear picture of what influences the cost, so you have a realistic sense of what you're pricing when you ask for a quote.
The size and complexity of your current site
How many pages are coming across? Is there a blog, and if so how many posts? Is there a shop? The more content there is to migrate, audit, and rebuild, the more time it takes — and time is what you're ultimately paying for.
The state of your content
A site where the content is current, well-organised, and ready to hand over is a very different project from one where the copy needs rewriting, the images need replacing, and half the pages need to be reconsidered from scratch. Content work is often the most time-consuming part of a migration and is frequently underestimated.
The domain and email situation
A straightforward domain pointing with a simple DNS update is one thing. A tangled situation involving a previous agency, a domain bundled with hosting and email, a recently registered domain that can't be transferred, or a Google Workspace setup that needs careful handling - that's another. The more complex the technical groundwork, the more time it takes.
Third party integrations
Every booking system, payment gateway, email marketing platform, or custom embed that needs to be identified, disconnected, and reconnected on the new site adds time to the project.
Design scope
A straightforward migration that replicates the existing site's look and feel on Squarespace is a different scope from a migration that incorporates a design refresh or a full redesign. The more design decisions there are to make, the longer the build takes.
Revisions
Most projects include two rounds of revisions as standard. Significant scope changes or additional revision rounds beyond what's included will affect the final cost.
Your availability and responsiveness
This one surprises people, but it's real. A project where content arrives promptly, feedback is consolidated and clear, and decisions are made without lengthy delays moves faster than one where things stall at the client end. Time spent waiting, chasing, or reworking due to unclear briefs is time that has to be accounted for somewhere.
A note on what migration projects typically involve as a baseline
Even the simplest migration is a more substantial piece of work than it might appear from the outside. At a minimum it involves discovery and planning, technical domain and DNS work, a full site rebuild on Squarespace, mobile optimisation, SEO setup, pre-launch preparation, go-live support, post-launch checks, and a handover walkthrough. That is a significant and specialised body of work and it is worth paying for properly.
Sites that have been underpriced tend to get underserved. The corners that get cut when a project is squeezed are usually the ones that matter: the thorough pre-launch checks, the careful domain coordination, the patient handover. These are not optional extras. They are the difference between a migration that goes smoothly and one that doesn't.
How to get an accurate quote
The best way to get a realistic sense of what your project will cost is to have a conversation. A discovery call (which with me is free and without obligation) gives us both the information we need to scope the project accurately and put together a proposal that reflects the actual work involved.
The mindset shift: from managed to self-managed
If you've spent years with an agency or developer managing your website on your behalf, the idea of running it yourself can feel daunting. Not because you're not capable but because you've never really been invited to try. The login credentials lived with someone else. The updates went through someone else. Over time, without really noticing it happening, you stopped thinking of the site as something you could touch. It became someone else's domain.
This is one of the most common things I encounter with clients coming from agency-managed WordPress sites, and it's worth naming it directly: what you're experiencing is not a lack of ability. It's a lack of familiarity. And familiarity, it turns out, comes quite quickly once you're actually in the driver's seat.
What self-management actually looks like
Let's be practical about this for a moment, because the reality of managing your own Squarespace site is quite different from what people imagine it to be.
It does not mean becoming your own IT department. It does not mean spending hours a week on technical maintenance, plugin updates, security patches, or backend administration. It means logging in when you need to, to update a page, publish a blog post, add a new product, change an image, update your contact details, or let your audience know what's happening in your business, and then closing that browser tab and getting on with your day.
That's it. That's what self-management looks like for the vast majority of Squarespace site owners.
Why Squarespace makes self-managed possible
Squarespace is genuinely designed for this. The interface is clean, logical, and consistent with the same editing experience across every page, every section, every element. There are no plugins to update, no backend configurations to manage, no code to touch unless you want to. The platform handles hosting, security, and software updates automatically and invisibly in the background.
One of the things I do when building a site is create what I call a sections masterlist which is a library of every section type used on your site, ready to be duplicated and dropped into any page. This means that adding a new page or a new section to an existing page doesn't require you to build anything from scratch or make any design decisions. You simply duplicate what's already there, swap in your content, and publish. It also means there is very little you can accidentally break, because the design system is already in place and the building blocks are already built.
In short: the site is designed to be edited by you, and it is designed to be difficult to break.
The support around you
Beyond the platform itself, you are not on your own. As part of the handover process I provide personalised Loom video walkthroughs: short, recorded screenshares that show you exactly how to do the most common tasks on your specific site, in plain language, that you can keep and refer back to whenever you need them. There's no trying to remember what was covered in a handover call six months ago. It's there, recorded, ready to watch again whenever you need a reminder.
In addition, Squarespace has one of the best customer support offerings of any website platform, a comprehensive library of help articles and tutorials covering almost any question you might have, as well as a live chat support team available around the clock. If you get stuck on something and I'm not immediately available, help is genuinely accessible.
When someone is given a well-built site, a clear handover, they naturally have the confidence to manage their own site.
What most people say the first time they log in
After all the anticipation, the nervousness, the years of feeling like their website was a complicated and slightly intimidating thing that other people managed, most clients say some version of the same thing the first time they log into their new Squarespace site.
"This is so much simpler than I expected."
"I can actually see where everything is."
"I think I can do this."
That moment: the realisation that this thing is actually manageable, that it makes sense, that it belongs to them and they know how to use it is one of the best parts of this work. It doesn't always get talked about in conversations about website migrations. But it probably should.
Pre-migration checklist
If you want to check if you’re in a good place to discuss a site migration, here is a checklist to work through that covers almost all the elements involved.
1. Your Domain
Do you know who your domain is registered with? (GoDaddy, Namecheap, domains.co.za, or another provider)
Do you have your own personal login to that domain provider account (not via an agency or third party)?
If an agency currently holds the login, have you requested your own independent access?
Do you know when your domain was last registered or transferred? (Domains registered or transferred within the last 60 days cannot be transferred to a new registrar)
Have you decided whether you are pointing your domain to Squarespace or transferring it? If unsure, this is worth discussing with your designer before the project begins
2. Your Email
Which of the following best describes your current email setup?
A personal Gmail, Yahoo, or other free email account with no connection to your domain (nothing to action)
An email address associated with your domain, set up and managed by your current hosting provider or agency (needs careful handling during migration)
Google Workspace or Microsoft 365 (MX records need to be verified and correctly in place)
Do you know who currently manages your email setup?
If your email runs through your current hosting or agency, has a plan been made to ensure email continuity during the migration?
Are you aware that email setup, migration, and device configuration (Outlook, Apple Mail etc) falls outside the scope of a website migration and may require separate IT support?
3. Your Current Platform and Hosting
Do you know what platform your current site is built on? (WordPress, Wix, Weebly, or other)
Do you have your own login to your current website platform?
Do you know who currently hosts your website, and is that separate from your domain provider?
If an agency manages your current site, do you have a named contact there who can assist with the handover process?
Are you aware of whether your domain, hosting, and email are bundled together or managed separately?
4. Third Party Services
Work through the following and note which apply to your current site:
Cloudflare or any other DNS management layer
Google Analytics or Google Tag Manager
Google Search Console (your domain will need to be reverified after migration)
Meta Pixel (Facebook/Instagram tracking)
Email marketing platform (Mailchimp, Flodesk, or similar)
Booking or scheduling system (Acuity, Calendly, Mindbody, Fresha, Nightsbridge, or similar)
Payment gateway (Stripe, PayPal, PayFast, Yoco, or similar)
Social media feed integrations (Instagram feed, embedded video, podcast player)
Any custom code blocks or embed codes inserted by a developer
Google Business Profile linked to your domain
WhatsApp Business click-to-chat
Any other tools, widgets, or integrations you're aware of
For each service that applies, note whether you have your own login and access to that account.
5. Your Content
Have you done a rough audit of your current site — how many pages, how many blog posts, whether there is a shop, what documents or downloads exist?
Have you made a decision about what content is coming across, what needs updating, and what is being left behind?
Do you have access to your original high resolution images, or are they only accessible via the current site?
Is your written copy current and reflective of where your business is today, or does it need rewriting?
If copy needs to be written or substantially rewritten, have you decided who will do that and when?
If your photography is outdated, have you made a plan to update it before or during the build?
Are there any images on your current site that may belong to a photographer or agency and have licensing implications?
6. Design and Brand
Are you migrating your existing design to the new platform, or are you incorporating a design refresh or full redesign?
Do you have current brand assets — logo files (preferably in SVG or PNG format), brand colours (hex codes if possible), and font names?
Does your current brand still feel reflective of who you are and where your business is going, or is a brand refresh worth considering?
If a redesign is part of the scope, has this been agreed and included in your proposal?
7. Timeline
Do you have a target go-live date in mind?
Is that date realistic given the content collection, build, review, and DNS propagation window involved?
Have you confirmed that someone with access to the domain provider account will be available and responsive during the go-live window?
Is your go-live date avoiding Fridays, weekends, and public holidays? (If something goes wrong, you want business hours available for troubleshooting)
Have you built in a buffer of at least 5 business days between DNS changes and any critical business events or launches?
8. Practical Readiness
Do you have a clear understanding of what your designer does and does not cover particularly around email, IT support, and domain management?
Do you know who to contact if something outside the designer's scope needs attention (IT support, email provider, domain provider help desk)?
Have you set aside time in your schedule for content collection, site review, and feedback, these are your responsibilities in the process and the project moves at the pace you're able to contribute
Are you clear on the payment terms and what is included in the proposal?
A final note before you begin
No checklist will account for every variable. Migrations are living processes and something unexpected almost always surfaces along the way. But the purpose of this checklist is not to eliminate uncertainty. It's to make sure that the things that can be known and prepared for in advance are known and prepared for so that when something unexpected does arise, there is enough clarity, trust, and groundwork in place to handle it without it derailing the whole project.
If you've worked through this list and feel ready, or ready enough, the next step is a conversation.
Frequently Asked Questions
How long does a migration take?
The honest answer is: it depends, and anyone who gives you a fixed number without knowing the specifics of your project is guessing. A straightforward migration of a small site with current content, a clean domain setup, and no complex integrations can move relatively quickly. A larger site with a significant blog archive, a shop, multiple third party integrations, a tangled domain situation, and content that needs rewriting will take considerably longer. As a general guide, most migrations (from first briefing to go-live) take between four and eight weeks. The variable that most often affects timeline is content: how quickly it can be gathered, reviewed, and signed off. The build itself is rarely the bottleneck.
Will my SEO be affected by the migration?
This is one of the most common concerns, and it's a fair one. The short answer is: a well-managed migration should have minimal lasting impact on your SEO. The longer answer is that any platform change involves some degree of transition. Search engines need time to recrawl and reindex your new site, and if URLs have changed, redirects need to be in place to make sure existing links and search results don't lead to dead pages. Done carefully, with proper redirects, a reverified Google Search Console, and Squarespace's built-in SEO tools correctly configured, most sites maintain their search presence and many actually improve over time thanks to Squarespace's cleaner code and faster loading templates. What causes lasting SEO damage is a poorly managed migration: one where redirects aren't set up, where the new site isn't submitted to Google, or where significant content is lost or removed without thought. This is why the post-launch checklist matters.
What happens to my old site?
Your old site doesn't disappear the moment the new one goes live. The two exist in parallel until the DNS changes have fully propagated and the new site has taken over on your domain. Once that process is complete, your old site remains on its original platform until you cancel that subscription or hosting arrangement. It's worth keeping the old site accessible (without renewing it, just leaving it as is) for a short period after go-live, as a reference in case anything needs to be checked or cross-referenced. Once you're confident everything is correctly in place on the new site, you can cancel the old hosting or platform subscription.
Can I keep my existing domain name?
Yes, absolutely. Your domain name is yours and it is not tied to your platform. Whether you're moving from WordPress, Wix, or Weebly, your existing domain comes with you. You have two options: you can point your domain to Squarespace while keeping it registered with your current provider, or you can transfer the domain registration itself to Squarespace. Both options result in the same end state: your existing domain pointing to your new Squarespace site. Which option is right for you depends on your specific situation and is worth discussing early in the process.
Do I need to be technical to manage my own Squarespace site?
No. This is probably the question I most want to answer clearly and directly. You do not need any technical knowledge to manage a Squarespace site on a day to day basis. You do not need to know what a DNS record is, how HTML works, or what a plugin does. Squarespace is designed to be edited by real people running real businesses: the same interface, the same logic, across every page and every section. Most of my clients update their own sites independently. The learning curve is real but it is short, and a proper handover including personalised video walkthroughs of your specific site means you finish the project with the knowledge and confidence to manage it yourself.
Will I lose my blog posts and old content in the migration?
Your content doesn't disappear but it doesn't migrate automatically either. Blog posts, pages, images, and products all need to be manually rebuilt on the new Squarespace site. This is part of why the content inventory stage of the project matters: it's the opportunity to make deliberate decisions about what comes across, what gets updated, and what gets left behind. For sites with a large blog archive, this can be a significant piece of work and is worth discussing in terms of scope and timeline at the start of the project.
What if my current agency won't cooperate with the migration?
This comes up more often than you might expect, and it can be one of the more frustrating aspects of the process. Agencies occasionally become unresponsive, unhelpful, or slow to provide access or information when a client is leaving. The most important thing to know is this: your domain is yours. If you have your own login to your domain provider account (which you should, independently of any agency) then you do not need their cooperation to point your domain to a new site. Where things get complicated is when the agency holds the domain login, the hosting, and the email all under their own account. In this situation, firm and documented communication requesting the transfer of those assets is the starting point. In most cases, agencies do eventually cooperate. In rare cases, it may be necessary to contact your domain provider directly to establish ownership. This is one of the reasons I always recommend establishing your own independent access to your domain provider account as early as possible ideally before the migration process even begins.
What if I want to make changes to the site after it goes live?
That's entirely the point. Your Squarespace site is designed to be edited by you, whenever you need to. Updating a page, adding a blog post, changing an image, adding a new product, updating your pricing - all of these are things you can do yourself, directly, without contacting anyone. For anything more structural such as adding a new page type, significantly redesigning a section, integrating a new third party service, I'm available for ongoing support. Most clients find they need very little help once the initial handover is done, but it's reassuring to know that support is available when they do.
What if something goes wrong during the migration?
Something small almost always does! A DNS record that takes longer than expected to propagate, an integration that needs to be reconnected, an unexpected complication with a previous agency or hosting setup. This is normal and it is not a reason to panic. The key is having someone guiding the process who has seen these situations before, stays calm under pressure, communicates clearly, and knows how to keep things moving forward. A buffer in the timeline (going live on a Monday or Tuesday rather than a Friday, with business days available for troubleshooting) is the single most practical thing you can do to make sure that when something unexpected surfaces, there is time and space to deal with it.
Do I need to cancel my old platform subscription straight away?
No, and in fact it's worth waiting a little before you do. Keep your old site accessible for a short period after go-live as a reference, and only cancel once you're confident everything on the new site is correctly in place, all content has been checked, and you no longer need it as a point of comparison. Once cancelled, access to the old platform and its content may be lost, so make sure you have everything you need before you pull the plug.
Can I switch to Squarespace if I have an online shop?
Yes. Squarespace has a fully featured ecommerce offering that covers product listings, inventory management, discount codes, shipping settings, and payment processing via Stripe and PayPal. For most small to medium sized shops, particularly those selling physical products, digital downloads, or services, it covers everything you need. Where Squarespace ecommerce has limitations is at the more complex end: very large product catalogues, highly customised checkout flows, or specific integrations that are only available on dedicated ecommerce platforms like Shopify. If you have a shop, it's worth discussing the specifics of your setup early in the process to make sure Squarespace is the right fit before the migration begins.
Working with me
If you've read this far, you probably have a fairly clear sense of what a migration involves, what to expect from the process, and what kind of person you want guiding you through it. So let me tell you a little about how I work, and whether we might be a good fit.
My name is Claire, and I've been designing and building Squarespace sites for over ten years. In that time I've worked with therapists, coaches, photographers, writers, florists, accommodation owners, pilates studios, NGOs, start-ups, and solo entrepreneurs, most of them coming to me from a place of frustration with a platform or an agency that had made them feel disconnected from their own digital presence. Helping them feel at home in their own website, genuinely at home, capable and confident, is the part of this work I find most satisfying.
What working with me looks like
I work with a small number of clients at a time, which means the person you speak to at the start of the project is the same person doing the work and the same person you'll hear from when something needs attention. There is no handoff to a junior team member, no disappearing into a production queue. Just a direct, consistent working relationship from first enquiry to final handover.
Something to note: I am not you IT department! In practical terms what that means is I won’t be backing up your email server or setting up email on your devices. What I am is someone with a thorough working knowledge of the full migration process: domains, DNS, email considerations, platform transitions, third party integrations, content, design, and the human side of all of it. I know where the complexity tends to live, I know what to watch out for, and I know how to keep things moving calmly when something unexpected surfaces, which it occasionally does.
I communicate in plain language. I explain things without making you feel like you should already know them. I build sites that are designed to be managed by the person who owns them. And I do a proper handover, not a rushed walk through a checklist, but a genuine transfer of knowledge that leaves you feeling equipped rather than dependent.
Who I work best with…
I work best with clients who are ready to take real ownership of their digital presence: people who want to understand the process, who are willing to show up for their part of it (content, decisions, feedback), and who are looking for a collaborative working relationship rather than simply handing everything over and waiting for a finished product to appear.
You don't need to be technical. You don't need to know anything about websites before we start. But you do need to be engaged because the best results come from projects where the client is genuinely invested in what we're building together.
If that sounds like you, I'd love to hear from you.
Before you get in touch
If you've worked through the pre-migration checklist earlier in this post, you'll already have a good sense of where you stand, what you have in place, what still needs to be resolved, and what questions you want to bring to a first conversation. You don't need to have everything figured out before reaching out. A discovery call is exactly the right place to work through what you know, what you don't know yet, and whether this project is ready to begin.
Discovery calls are free, without obligation, and usually last around 30 minutes. By the end of it we'll both have a much clearer picture of what the project involves and whether we're a good fit to tackle it together.
