Cloud Consultants near you

The first step is an application inventory with dependencies, because the thing that breaks a migration is almost always an undocumented link between two systems. For each application the decision is to retire it, replace it with a hosted product, move it unchanged, adjust it modestly, or rebuild it. Those five choices have completely different costs and timelines, and a proposal that treats them as one number is hiding the variance.

Identity usually moves first. Directory, single sign-on and multi-factor authentication have to be in place before workloads land, or you end up with two account systems and a permanent reconciliation problem. Network routing and name resolution follow.

Then data. Large datasets move over days, not hours, and the cutover plan needs a defined freeze, a verified copy and a tested way back. Ask what the rollback looks like for each wave and who decides to use it. A migration with no rollback plan is a migration that will be completed under pressure at two in the morning regardless of how it is going.

Every major provider publishes a division of duties, and the general shape is consistent: the provider is responsible for the security of the underlying infrastructure, and the customer is responsible for security in it. What that means in practice moves with the service model. On infrastructure as a service you own operating system patching, host configuration, network rules, encryption choices and identity. On software as a service, most of that disappears and what remains is identity, sharing settings and the data itself.

The consistent customer-side items are identity and access management, data classification, and configuration. Misconfigured storage, over-broad permissions and unused administrative accounts are customer-side problems in every model, and they are the ones that actually cause incidents.

Backup deserves its own line. Being in the cloud is not being backed up. Retention in a productivity suite is a retention policy, not an independent copy, and a deletion or a compromised administrator can still lose data. Ask specifically where a second copy lives and how a restore is tested.

Lock-in is not a single thing. Data lock-in is the cost and time to extract what you have stored. Service lock-in is dependence on proprietary managed offerings with no direct equivalent elsewhere. Skills lock-in is that your team and your consultant now know one platform well. The first is measurable, the second is a design choice, and the third is real but slower moving.

The practical question to put to a consultant is what it would take to move each workload to a different provider, and how that answer changes if they use a proprietary database or serverless platform rather than a standard one. Sometimes the proprietary route is plainly worth it. It should still be a decision someone made on purpose.

Write down the exit position while you are still happy: where the data lives, in what format it can be exported, who holds the account ownership, and what the documented architecture is. Cloud accounts should be owned by your company, with billing in your name, even where a consultant resells or manages them.

If you sell to federal agencies, FedRAMP is the gate. It is run under GSA's Technology Transformation Services and maintains a marketplace, a searchable database of FedRAMP authorized cloud services, the agencies that authorised them and the recognised assessors. Buying a service that is already authorised is a very different project from getting your own service authorised.

For health data, HHS treats a cloud service provider engaged to create, receive, maintain or transmit electronic protected health information on behalf of a covered entity or business associate as a business associate itself, which means a business associate agreement is required even though the provider may never look at the data. Encryption does not remove that relationship.

Sector overlays stack on top. A firm inside the FTC Safeguards Rule still owes encryption, access controls, multi-factor authentication and service provider oversight after moving to the cloud; the platform does not inherit the obligation. Ask your consultant to map each requirement to a specific control in the new environment rather than to the provider's compliance page.

Platform uptime commitments are published by the provider per service, and the remedy when they are missed is normally a credit against future usage, claimed by you within a set window. It is compensation for the platform fee, not for your lost business, and it is almost never material next to the actual cost of downtime.

Your consultant's commitment is a separate document. If they operate the environment after go-live, that agreement should say what they monitor, how fast they respond by severity, who can authorise emergency changes and how out-of-hours escalation works.

Availability is ultimately an architecture question, not a contract question. Running across more than one availability zone, or more than one region, costs more and is the only thing that actually keeps you online through a zone failure. Decide deliberately how much downtime the business can absorb, then buy the architecture that matches, rather than relying on a credit.