Every server, in about three hours: how a small IT team assessed its entire estate for AWS

Most small and mid-sized businesses know they should be looking at AWS. What holds them back is rarely the cloud itself. It's the first step: finding out what they actually run, how it all connects, and what it would cost to move. In a large enterprise, a migration team spends weeks on that. In an SMB it lands on the same one or two people who already keep everything else running.

This post walks through how one small IT team got that first step done in about three hours, what they ended up with, and the three questions worth answering before you plan a move of your own.

The question every small IT team gets asked

"What would it cost us to run on AWS, and what breaks if we move?"

It sounds like one question. To answer it honestly, you need three things, and each one is harder to produce by hand than it looks.

An inventory of every server and application

Most teams have a spreadsheet or a CMDB, and most of those have drifted. Servers get stood up for a project and never recorded. Applications get installed on hosts that nobody thinks of as theirs. The list you have is a starting point, not an answer.

A map of which systems depend on which

Dependencies usually live in the heads of the people who built the systems. Ask which servers the finance application talks to and you'll get a confident answer that misses the file share, the licence server and the scheduled job that runs at 2am. Miss one connection and something stops working on cutover day.

A sizing exercise for each machine

On-premises servers are often sized for peak load, or for hardware that was bought years ago. Copy those specs straight into AWS and you pay for capacity you don't use. A credible cost estimate needs each server sized from what it actually does, not from what it was given.

Done by hand, each of these takes days of logging in, checking, and cross-referencing. And by the time all three are finished, the first is already out of date.

Why it's harder for a small business

An SMB has the same questions to answer as an enterprise, with a fraction of the people. There's no migration team to second onto the project. The day job doesn't pause: tickets still come in, backups still need checking, users still need help. And production can't go down while someone investigates how it's put together.

The usual alternative is bringing in consultants to build the inventory. That works, but it means spending money before anyone knows whether the move is worth making. For a lot of small businesses, that's where the cloud conversation stalls.

What it looked like in practice

A US non-profit credit counselling organisation, working with one of our AWS partners, used CHAI DART™ to assess every one of its 28 production servers, spanning Windows and Linux and two different login methods (SSH and Kerberos). Building the same inventory by hand typically takes weeks of spreadsheet work.

The work ran in three short sessions, fitted around the team's normal day, using credentials they already had. No agents were left on the servers, no custom scripts were written, and the network didn't need changing.

The mix of systems matters here. A mixed estate is exactly where manual and scripted discovery tends to slow down: Windows and Linux need different approaches, and so do SSH and Kerberos logins. Each combination usually means another script to write, another set of permissions to sort out, another round of checking the output. Here, they were handled in the same pass.

What the team walked away with

At the end of those three sessions, the team had everything leadership would ask for:

• A complete inventory. Every server, what runs on it, and its running processes, collected from the systems themselves rather than from memory or an old spreadsheet.
• A map of how their systems connect. Which systems talk to which, which ones need to move together, and which ones can't go down.
• A full AWS cost estimate. Every server sized, with an annual cost for their chosen region, ready to export and put in front of leadership.

That changes the conversation. Instead of "we think it might cost about this", the team could show a server-by-server figure and the dependency picture behind it. That's the material a real decision gets made on, whether the answer is to move everything, move some of it, or not move yet.

How a CHAI DART assessment runs

There's no project plan to write first. An assessment follows the same four steps whatever the size of the estate:

1. Deploy the appliance. CHAI DART runs on a single VM, installed from a step-by-step guide.
2. Connect the credentials you already use. SSH for Linux, your existing Windows logins, including Kerberos. Nothing gets installed on the servers.
3. Let discovery run. Servers, applications, running processes and network communication are collected while production carries on as normal.
4. Review and export. Topology views show how everything connects, and the AWS Cost Comparison turns it into an annual figure you can share.

Why it doesn't need a migration team

One appliance, a handful of commands

CHAI DART runs on a single VM and installs from a step-by-step guide. There's no cluster to build, no infrastructure to provision first, and no specialist skills needed to get it running.

Agentless discovery

It collects servers, applications, running processes and network communication, and leaves nothing behind. There are no agents to roll out to every server, no change requests to raise for each one, and nothing to clean up afterwards.

Dependencies mapped for you

Topology views show which systems talk to which, with no whiteboard needed. The connections come from observed network communication, so they include the ones nobody remembered to mention.

Answers in business terms

The AWS Cost Comparison sizes every server and gives an annual cost for your chosen region, ready to export for leadership. The output is a number a finance team can work with, not a technical report someone has to translate.

What goes wrong when the assessment is skipped

It's tempting to go straight to the move, especially for a small estate. These are the problems that tend to follow:

• Like-for-like sizing. On-premises specs get copied straight into AWS, and the monthly bill comes in well above what anyone expected.
• The forgotten dependency. A file share, a licence server or a scheduled job that nobody listed, discovered only when it stops working.
• The wrong order. A system moves before the systems it relies on, adding latency or breaking it outright.
• A business case nobody trusts. A cost figure without a server-by-server breakdown behind it is hard to defend when leadership starts asking questions.

None of these are cloud problems. They're all things you didn't know about your own estate before you started.

Three questions to answer first

Before anyone writes a migration plan, ask:

1. Do we know every server we run, and what's on it? Not what the spreadsheet says. What's actually running today.
2. Which systems depend on each other, and which ones can't go down? That decides what moves together, and in what order.
3. What will it cost to run on AWS, and can we show that before we commit? With a breakdown that stands up to questions from leadership.

Start with what you have

CHAI DART is available on AWS Marketplace. To see what an assessment of your estate would look like, talk to our team.