Where Should Your Workloads Run? Three Examples That Show How to Decide

Cloud strategy is rarely a question of choosing one place to run everything. Most IT teams manage a mix of established business applications, newer cloud services, and emerging AI workloads. Each comes with its own requirements, and a move that makes sense for one application may create unnecessary cost or complexity for another.

At US Signal’s annual Cloud + AI Readiness Virtual Summit, Pat Cannon, Justin Ellison, and Taylor Greiner walked through three workloads to show how they make placement decisions. Their discussion covered technical requirements, cost, and the work involved in supporting an application after it moves.

“There is a right place for a specific workload at a specific point in that workload’s life.”
Justin Ellison, Senior Solutions Architect, US Signal

That last phrase matters. Hardware ages, applications change, and options that were impractical a few years ago may become viable. The right decision is one that meets the workload’s needs now and can be revisited later.

A legacy ERP application with deep dependencies

Consider an ERP application that has supported a business for decades. Its usage is steady, growth is modest, and other applications depend on it. Moving the ERP system may be possible, but separating it from those applications could create performance problems. Modernizing everything at once would be a much larger project.

Justin described a customer that moved much of its application environment from on-premises infrastructure into US Signal’s private cloud. The customer also moved its iSeries environment into the same data center so the connected applications could remain close together.

“Trying to force that into a cloud-native platform would mean a lot of re-architecting while they were also trying to lift and shift all of their workloads into a private cloud environment.”
Justin Ellison

The customer’s existing hardware needed replacement, but it was not yet ready to change the business processes supported by the iSeries application. Keeping those systems together addressed the immediate need without making application modernization a condition of the migration.

Years later, the answer changed. The customer developed a new long-term strategy and began moving away from the iSeries platform toward SaaS. Its earlier placement decision still made sense for the stage the application was in at the time.

A transaction database where response time matters

Now consider a database supporting an online transaction application. Users interact with a web or application front end, which relies on the database to return results quickly. The location of each component can affect the experience users have with the application.

Pat used this example to explain why a team should establish its technical requirements before comparing environments.

“If we know a workload requires sub 50 milliseconds latency, that’s probably a hard gate.”
Pat Cannon, Field CTO and Vice President of Solution Architecture, US Signal

The 50-millisecond figure was an example, not a threshold for every transaction application. An IT team needs to measure what its own application requires and determine whether each proposed environment can meet it. It also needs to consider availability and whether the application’s components can fail over together in a consistent state.

Those findings might support keeping the application on-premises, moving it to a private cloud, or placing equipment in a colocation facility. The decision starts with how the application works, including which systems depend on one another and how quickly they need to communicate.

A small language model that may not need a GPU

AI brings its own placement questions, starting with the hardware.

“Do I need a GPU? Can I run this on specialized hardware?”
Taylor Greiner, Director of Innovation, US Signal

Taylor described a small, task-specific language model used for work such as classification or summarization. Depending on the model and its performance requirements, that workload might run on CPU-based infrastructure, including ARM-based processors. If so, the team has more options to compare than it would if it assumed a GPU was required.

It also needs to consider the workload’s usage and its data. A hosted API, public cloud infrastructure, private cloud, and on-premises deployment can have different cost patterns and data-handling considerations.

“This is an inference workload. It needs to stay close to the data. We want to know where that data lives.”
Taylor Greiner

Calling something an “AI workload” does not tell you where it belongs. The model, the task, expected demand, and the data it uses all affect the answer.

Make the decision, then revisit it

Across all three examples, the team first identifies requirements that may limit its options: application dependencies, latency, hardware needs, and data location. It can then compare the environments that meet those requirements on cost and operational effort.

That comparison should remain open as the workload changes. The ERP customer’s later move toward SaaS is a good reminder that a sound decision does not have to be permanent.

“Drop your bias around different operating models.”
Pat Cannon

Start with what the workload needs. Then choose an environment that meets those needs, and make time to reconsider the decision as the application evolves.

Where should you start? Use US Signal’s Workload Placement Finder to explore which infrastructure models may fit your applications and where a closer assessment is needed.