Question 1

Will our site go down during the migration?

Accepted Answer

For most web and SaaS workloads the visible interruption is minutes rather than hours, and close to zero for read-only traffic. We lower DNS TTLs in advance, run old and new in parallel, and keep the write freeze as short as the data move genuinely requires. Where a database cannot be replicated live, we schedule the cut in your quietest window and tell you the honest expected duration before you approve the date.

Question 2

Will the cloud cost us more than what we pay now?

Accepted Answer

Sometimes it will, and anyone promising a saving before seeing your workload is guessing. A small, steady site on cheap shared hosting is often cheaper exactly where it is; the real gains usually come from removing server maintenance, absorbing traffic spikes without permanent over-provisioning, and retiring capacity you no longer use. We build the cost model before the migration so the comparison is a number you can check line by line.

Question 3

Can you migrate if our previous developer or host will not cooperate?

Accepted Answer

Usually yes. With administrative access to the hosting panel, the domain registrar and the database, we can inventory and move a site without the previous provider's help, and this is common on older PHP and WordPress-era projects. The genuine blockers are missing credentials and source code that exists only on the live server, so the first thing we check is what you actually hold.

Question 4

Which cloud should we choose — AWS, Azure or Google Cloud?

Accepted Answer

It depends far less on feature lists than on what your team already runs and hires for. Microsoft-centric organisations tend to land better with Azure Migration, data and analytics-heavy teams often prefer Google Cloud Migration, and AWS Migration remains the broadest default. For many web and SaaS products, a managed application platform plus a managed PostgreSQL provider is simpler and cheaper than any of the three, and we will say so when that is the honest answer.

Question 5

Do you hold cloud or security certifications?

Accepted Answer

We hold no certification we could point at, and we are not a certification body — we will not imply otherwise. The cloud providers are certified for their own infrastructure, which covers the platform layer but says nothing about how your application is configured on top of it. We implement controls and produce the documentation assessors ask for; the certificate itself is issued by an accredited third party, never by us.

Question 6

Should everything move to the cloud?

Accepted Answer

No, and a migration plan that says otherwise deserves scrutiny. Workloads with heavy constant compute, strict data-residency constraints, or licences tied to physical hardware can cost more in a cloud than on machines you already own. We flag those during discovery and recommend leaving them, deferring them, or splitting the estate — a partial migration is a legitimate and often correct outcome.

Question 7

How long does a migration take?

Accepted Answer

A single web application with a modest database is typically a few weeks from discovery to cutover, and most of that time goes on mapping, rehearsal and testing rather than the move itself. Estates with several interlinked systems, file storage and third-party integrations take longer, and we stage them so each cut is small enough to reverse. We commit to a cutover date only after the rehearsal has shown how long the data move really takes.

Question 8

What about our old WordPress or PHP site?

Accepted Answer

Legacy sites are a large share of this work and they are rarely a clean lift. The realistic options are rehosting on managed infrastructure to buy time, or re-platforming onto a modern stack with content, URLs and redirects migrated so search rankings survive. We audit the PHP version and plugin dependencies first, because an end-of-life runtime or an abandoned plugin is a security problem that moving it elsewhere does not fix.

Question 9

What are egress costs, and why do you keep raising them?

Accepted Answer

Egress is what a provider charges to send data out of its network: images, video, API responses, backups leaving the region. It is the single line item that most often makes a cloud estimate wrong, particularly for media-heavy sites, and it also makes leaving later more expensive than arriving. We model it from your real traffic and, where it dominates, put a CDN in front or pick a provider whose pricing suits your traffic shape.

Question 10

What do we actually get at the end?

Accepted Answer

A running environment, infrastructure defined as code where practical, a documented architecture with the cost model behind it, monitoring and alerting with an owner against each alert, backups verified by a real restore, and runbooks for deploys, rollbacks and incidents. If you want us to stay on for operations we can, but the handover is written on the assumption that you might not.

How can we help?

Cloud Migration
FAQ

Helpful
information

Getting Started

Timeline

Pricing

Support

Still have questions?

Cloud MigrationFAQ

Helpfulinformation