A server migration is a data-consistency problem wearing an infrastructure costume. The move itself is routine; what goes wrong is the delta written after the copy and the dependency nobody remembered. We rehearse the cutover before we perform it.
Moving files and a database is well-understood work. What breaks a migration is everything adjacent to it: a scheduled job pointing at the old host, a mail-sending integration with an allowlisted IP, a CDN origin still resolving to the previous address, a third-party API validating a TLS certificate. These surface in the minutes after a cutover, when the pressure to roll back is highest and the information needed to decide is least available.
You need the move executed with the risk managed rather than a plan that assumes everything will copy cleanly.
Your provider has given you a date and you need the migration scoped, rehearsed and executed before it arrives.
You know the current arrangement is not working and you need the move handled by someone who will tell you what could go wrong before they start.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
The difference between a planned thirty-minute window and an unplanned weekend is almost always whether the cutover was tested somewhere first.
Anything written to the source after the initial copy and before the switch has to be reconciled. Skipping or miscalculating that window is the most common cause of a migration that appears to succeed and then loses transactions.
Scheduled jobs, mail allowlists, CDN origins, webhooks and API IP restrictions. Each is individually trivial and collectively capable of taking a migrated site down after a technically successful move.
A same-domain server migration should have no search consequences at all. The moment the domain or the URL structure changes as well, it becomes a different project with a different risk profile — and conflating the two is how sites lose visibility during infrastructure work.
Each of these is work we carry out, not an area we advise on.
A written record of everything the move has to account for: application and its runtime, files and their ownership, databases and their collation, mail sending and receiving, DNS records including the low-TTL and easily-forgotten ones, scheduled jobs, TLS certificates, CDN configuration, storage buckets and third-party integrations.
Sizing the destination against observed load rather than the current specification, with the application, database and static assets separated where that is warranted. A migration is the natural moment to fix an architecture you already know is wrong — and also the moment when scope creep is most expensive, so this is agreed explicitly rather than opportunistically.
Copying the bulk of the data ahead of the window so the cutover handles only the delta. This is what turns a migration from an hours-long outage into a short one, and it is the single highest-value thing that can be done in advance.
Running the destination as a working site before it faces the public — application boot, database connectivity, write paths, mail, background jobs, authentication, and any integration that validates an origin or an address.
TTL reduction ahead of the window, a documented record set, the exact sequence of changes, who executes each, and the decision point at which the rollback is triggered rather than debated.
A tested way back. The rollback is defined and verified before the cutover starts, because a rollback invented during an incident is not a rollback.
Application health, write paths confirmed against real data, log review for errors that do not surface on the front end, and a defined observation period before the old environment is decommissioned.
When the migration also changes the domain or the URL structure, redirects, canonical signals and sitemap accuracy are verified as part of the work — with the understanding that this portion is a search engagement.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Same-domain server move, domain change, or platform change. They read similarly in a brief and behave completely differently in execution. The first step is agreeing which one is happening, because two of the three carry search risk and one does not.
The inventory is written down and reviewed. The components that cause outages are the ones nobody listed — the cron job, the outbound mail path, the IP allowlist — so the inventory deliberately goes past the web application.
Bulk data moves before the window; the window handles the delta. This is the difference between a planned short outage and an unstructured evening, and it is decided at planning time rather than improvised.
The destination is exercised as a working site, and the cutover sequence is run against it with a rollback. That rehearsal is what converts the window from a hope into a procedure.
A specific condition — not a feeling — at which we revert. Deciding this in advance is what stops an incident becoming an argument about whether to continue.
Read paths often work immediately while writes fail quietly. Real write paths are confirmed, the environment is observed for an agreed period, and only then is the old one retired.
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Engagements where this capability was the substance of the work rather than a line item.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
Since 2021, Soludome has managed infrastructure, site performance and technical SEO across GuzziTech and RideMalibu as a connected web estate. The engagement includes dedicated infrastructure and continuing operational ownership.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
That is a search-preserving migration rather than an infrastructure one.
Website migrations with search preservedSource-schema conversion is a separate discipline with its own evidence position.
vBulletin to XenForo migrationArchitecture and capacity design is a different engagement.
Infrastructure engineeringPlatform-specific migration considerations for that CMS are covered separately.
WordPress developmentUsually a short planned window, and occasionally none. Bulk data is copied in advance so the cutover handles only the delta, and read-only traffic can often be served while the switch happens. Whether your application can tolerate a read-only period is a property of your application rather than of the migration, and we will tell you which case yours is after the inventory rather than before it. What we will not do is promise zero downtime as a headline — DNS propagation and caching are not entirely under our control.
A same-domain server migration should have no search consequences at all: the URLs do not change, so there is nothing for a search engine to re-evaluate. The exception is when the move is treated as an opportunity to also change domain, URL structure or platform — at which point it is a different project with real search risk, and it should be planned as one from the start. If that is your situation, say so, because it changes the sequencing substantially.
You do, and that does not change. We work through access you grant and revoke, and the last step of our involvement returns everything to your control with the new configuration documented. We do not take ownership of a domain or a hosting account as part of a migration, because that would make us a dependency rather than a provider.
It depends almost entirely on the size of the data and the number of integrations, and not much on the size of the site's traffic. A small application with two integrations is a different project from the same traffic volume with a mail system, a CDN and six third-party services. The estimate follows the inventory, and we will not give one before it.
Yes, and moving between providers is the common case rather than the exception. We do not resell hosting, so the recommendation is based on what the application needs rather than on a margin — and if the honest answer is that your current provider is fine and something else is the problem, that is what we will say.
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.