What to Bring to a Workload Placement Assessment

A workload placement assessment answers a practical question: for each workload you run, where should it live? Some belong in public cloud. Some would cost less and run better on dedicated infrastructure. Some fit best in a hybrid setup. The quality of that answer depends almost entirely on the data you bring to it. With a billing total and a rough instance count, you get a rough guess. With real usage data, an inventory, and your commitments and constraints, you get a plan you can act on.

The usual problem is timing. A team books an assessment, shows up with a monthly bill and a spreadsheet of instances, and spends the first meeting finding out what’s missing. The analysis waits while someone exports usage data, digs up commitment end dates, and draws the architecture from memory.

Gathering the right inputs up front turns that into one productive session. Here’s what to bring.

1. Billing Data From Every Provider

Start with detailed billing exports, not just invoice totals:

• AWS: Cost and Usage Reports
• Google Cloud: billing data exported to BigQuery
• Azure: cost exports from Cost Management
• AI platforms: usage and billing data from OpenAI, Anthropic, or others you use

Three to twelve months is ideal. One month can hide seasonal patterns, and a single quarter can miss annual spikes.

Why it matters: Detailed billing data breaks spend down by service, resource, and region, which is what lets an analysis tie costs to specific workloads.

The fast way to get it: Economize connects to AWS, Google Cloud, and Azure through agentless integrations, along with usage-based AI platforms like OpenAI and Anthropic, and organizes the data for you. It also includes a migration estimator that matches your workloads to equivalent configurations across providers, with OpenMetal now part of that comparison.

2. Utilization Data

Billing tells you what you paid for. Utilization tells you what you used. Bring CPU, memory, storage, and network usage for your main workloads over at least 30 days, and longer if you can.

Why it matters: Placement depends on how steady a workload is. A workload that runs at a consistent level is a strong candidate for dedicated hardware. One that spikes briefly and sits idle the rest of the month often belongs on usage-based pricing. Utilization also shows overprovisioning, so the comparison is made against what you actually need, not what you happen to be paying for.

3. An Inventory of What You Run

List the workloads, not just the resources. For each one, note:

• The instances or containers it uses, with their sizes
• Its storage, including block volumes, object storage, and database storage
• The managed services it depends on
• Who owns it on your team

Why it matters: Placement decisions happen per workload. An inventory that groups resources by application makes it possible to say “this service moves, that one stays” instead of “some of this bill might move.”

4. Data Transfer and Network Costs

Pull out your data transfer charges separately: data leaving the provider to the internet, traffic between regions and availability zones, NAT gateway processing, and VPN or dedicated connection fees.

Why it matters: Network charges are an easy place for placement decisions to go wrong. Moving a workload without the data it reads can create new cross-provider traffic. And bandwidth-heavy workloads are often the ones with the most to gain from a different pricing model. Our article on what hybrid cloud networking actually costs explains how to read those charges.

5. Commitments and Contract Dates

List every commitment you’ve made: reserved instances, savings plans, committed use discounts, and enterprise agreements, with the amount committed and the end date for each.

Why it matters: A workload covered by a commitment that runs another two years is paid for either way. Moving it early doesn’t save money until the commitment ends. Commitment dates can decide the order of a migration more than anything else.

6. Architecture and Dependencies

Bring a diagram, even a rough one, showing how your workloads connect: which services call which, where data flows, and what depends on what.

Why it matters: Dependencies determine what has to move together. Splitting a chatty application from its database across providers can cost more than leaving both where they are. The diagram also surfaces proprietary services that make a workload harder to move.

7. Requirements and Constraints

Write down the things that limit your options:

• Location: where your users are, and any data residency requirements
• Performance: latency targets and workloads sensitive to noisy neighbors
• Security and compliance: controls your auditors expect, and who signs off on infrastructure changes
• Team: who will run the infrastructure, and how comfortable they are with the platforms involved
• Timing: deadlines such as a contract renewal, a data center closure, or a product launch

Why it matters: The cheapest placement isn’t useful if it misses a requirement. Constraints narrow the options before cost comparison begins.

8. Growth Plans

Share what you expect over the next 12 to 24 months: new customers, new products, expected traffic growth, and planned projects.

Why it matters: A placement that fits today can be wrong in a year. If you’re adding capacity every time you sign a customer, a model with predictable per-server pricing may matter more than today’s numbers suggest.

How to Gather It in Two Weeks

Most of this data already exists. It’s just spread across teams. A short, owned plan gets it together quickly:

• Days 1 to 2: Assign owners. Finance or FinOps takes billing exports and commitments. Platform or SRE takes utilization and network data. Application owners take the inventory and dependencies.
• Days 3 to 7: Export and connect. Turn on detailed billing exports if they aren’t already running, or connect your accounts to a cost tool that collects them for you. Pull utilization from your monitoring stack.
• Days 8 to 10: Build the inventory. Group resources by workload and note owners, managed services, and storage for each.
• Days 11 to 12: Draw the dependencies. A whiteboard photo is fine. What matters is which services talk to which.
• Days 13 to 14: Write down constraints and growth plans. Get sign-off from whoever owns budget and roadmap.

If one piece is hard to get, don’t hold up the rest. An assessment with a gap you’ve flagged is still far more useful than one delayed for a perfect dataset.

What a Useful Assessment Gives You Back

With those inputs, an assessment should hand you more than a total savings figure. Look for:

• A placement for each workload: stay, move, or hybrid, with the reasoning behind each
• A cost comparison at realistic utilization, not at full capacity
• Optimizations for what stays. Rightsizing, idle resources, and commitments that don’t match usage
• A sequence for what moves, ordered by savings, effort, and commitment dates
• The risks, including dependencies, data transfer, and anything that needs a decision from your team

How OpenMetal Labs Approaches It

OpenMetal Labs runs placement assessments from your actual public cloud spend. Labs helps you optimize what you’re running now, identifies where a workload has crossed the point at which private infrastructure costs less, and treats hybrid as a fully supported outcome when that’s the right answer. If you want a starting point, we also offer free cloud cost audits.

How a Deployment Works If Workloads Move

If the assessment recommends moving some workloads to OpenMetal, here’s what happens next:

• We plan ahead. We scope the environment for the workloads that are moving, plan capacity with room for your growth plans, and source and stage the hardware against your go-live date.
• You decide. You choose which workloads move first, the hardware configuration and location, and your cutover approach.
• We hand over. You get a running environment with full admin access and a private Slack channel with our engineers. Ramp pricing and running old and new environments in parallel during cutover are available, so you can line the move up with commitment end dates instead of paying twice.

A Pre-Assessment Checklist

• Billing exports from each provider, three to twelve months
• Utilization data for main workloads, at least 30 days
• Workload inventory with owners
• Data transfer and network charges broken out
• All commitments with amounts and end dates
• Architecture diagram with dependencies
• Location, performance, security, team, and timing constraints
• Growth plans for the next 12 to 24 months

Who This Is For

This is most useful if you:

• Spend enough on public cloud that the bill gets executive attention
• Run a mix of workloads and suspect some don’t belong where they are
• Have commitments, renewals, or deadlines that affect timing
• Need a placement plan your finance and engineering teams both trust

It’s less useful if you:

• Run a single small workload with an obvious answer
• Have already committed to a full move for reasons other than cost

The Short Version

A placement assessment is only as good as the data you bring to it. Bring detailed billing, real utilization, an inventory by workload, your network charges, your commitments, your dependencies, and your constraints, and you’ll leave with a plan instead of a guess.

To get your billing and usage data in shape, start with Economize. When you’re ready for a workload-by-workload plan, talk with our team about an assessment through OpenMetal Labs, or apply for a proof of concept to test workloads on dedicated hardware.

Frequently Asked Questions

What is a workload placement assessment?

It’s an analysis of each workload you run to decide where it should live: in public cloud, on private infrastructure, or in a hybrid setup. It weighs cost, utilization, dependencies, data transfer, commitments, and requirements.

What data do I need for a placement assessment?

Detailed billing exports, utilization data, a workload inventory, data transfer charges, commitment details, an architecture diagram, your constraints, and your growth plans.

How much billing history should I bring?

Three to twelve months. Shorter periods can hide seasonal patterns and annual spikes.

Why do commitments matter for placement?

Workloads covered by reserved instances or savings plans are paid for until the commitment ends. Commitment end dates often decide which workloads move first.

Can Economize help gather the data?

Yes. Economize connects to AWS, Google Cloud, and Azure, plus AI platforms like OpenAI and Anthropic, and organizes your cost data. Its migration estimator also compares workloads against equivalent configurations, including OpenMetal.

Does an assessment always recommend moving off public cloud?

No. A useful assessment recommends moving only the workloads that fit private infrastructure, optimizing the ones that stay, and treating hybrid as a valid outcome.