IT Guidance for Cloud Clients in the Pacific Northwest

I spent three hours last month on a call with a manufacturing client in Bellingham who wanted to know if they should migrate their ERP to Azure. Fair question. Except when I asked what problem they were solving, the answer was "everyone says we should be in the cloud." That's not a problem. That's a rumor.

Cloud works when it solves a specific pain point you can measure. It doesn't work as a general principle or a compliance checkbox. The Pacific Northwest has good connectivity in most metro corridors, but we're not Silicon Valley. Latency to AWS US-West-2 from Seattle is manageable. From Wenatchee, less so. From a job site outside Forks with LTE coverage that drops when it rains? You're in a different conversation entirely.

Here's what I tell people: cloud isn't the destination. It's a tool. Sometimes the right one. Often not. The question isn't "should we use cloud" - it's "what are we trying to accomplish, and does cloud get us there cheaper, faster, or more reliably than the alternatives?"

The Real Costs Nobody Mentions

You see the monthly Azure or AWS invoice and it looks reasonable compared to a hardware refresh. On paper, sure. What you don't see upfront is egress fees, storage tiering costs, and the bill you rack up when your team pulls data out of the cloud for reporting or backups. Those line items don't show up in the migration proposal. They show up six months in when finance asks why the cloud bill is 40% higher than projected.

I had a client in Tacoma running a SQL workload they moved to AWS RDS. Migration went fine. Performance was fine. Then they needed to integrate a new reporting tool that pulled large datasets nightly. Egress costs doubled their bill in thirty days. The reporting tool vendor didn't warn them. AWS didn't warn them. The MSP that did the migration didn't mention it because they billed a percentage of cloud spend. Incentives, right?

We moved them to a hybrid model - SQL back on-prem, read replicas in RDS for the stuff that actually needed cloud elasticity. Cut their monthly spend by half and improved query performance on the local workloads. But nobody pitches hybrid, because hybrid doesn't sound like innovation. It sounds like compromise. Which it is. That's the point.

Bandwidth Isn't Uniform Out Here

Seattle and Portland have solid pipes. Spokane's getting better. But the Pacific Northwest isn't a monoculture. If you're running distributed operations - branch offices, remote job sites, field techs - your bandwidth story changes every twenty miles. I've seen clients with a headquarters in Bellevue and a branch in Ellensburg treat both locations like they have identical connectivity. They don't.

Cloud-first makes sense for headquarters with gigabit fiber. It makes less sense for the branch running on a bonded T1 because that's what the building supports. You can't architect around bandwidth you don't have. And upgrading connectivity isn't always an option - either because of cost or because the infrastructure literally isn't there.

This matters more than vendors let on. If your application assumes low latency and high throughput, and your branch office has neither, you've built something that works in one location and fails in the others. The fix isn't "add more cloud." It's designing for the constraints you actually face.

What Actually Works

Cloud works great for workloads with variable demand. Test environments, dev pipelines, applications that spike seasonally - those are good fits. You spin up capacity when you need it, you shut it down when you don't. That's the value proposition functioning as advertised.

Cloud works poorly for steady-state workloads you can predict twelve months out. If you know you need sixteen cores and 64GB of RAM year-round, buying the hardware and running it for five years is almost always cheaper. The TCO math isn't complicated. It just doesn't fit the narrative vendors are selling.

The other place cloud makes sense: disaster recovery and business continuity. Replicating critical workloads to a second region gives you failover options you can't easily build on-prem without doubling your hardware spend. That's a legitimate use case. But it's not the same as migrating everything because someone read an article.

What You Actually Need

You need someone who'll look at your invoices, your bandwidth maps, and your actual usage patterns before recommending anything. Our team - cumulative 100+ years in IT across the board - we start every client engagement the same way. Show us what you're running, where it's running, what it costs, and what problems you're trying to solve. Then we'll tell you whether cloud makes sense, and for which workloads.

Not always. Not never. The answer depends on what you're doing and where you're doing it.

If you're in the Pacific Northwest and your current IT partner keeps pushing cloud without asking questions, you might be working with the wrong partner. Call us at The Craftwork Group. We'll review your environment, no obligation, and tell you what actually makes sense for your business. Visit craftworkgrp.com or reach out directly. Let's pencil it out together.