ATLAS PROJECT
Enterprise Transformation Model
A hierarchical model of source and target estates that lets technical, operational, and financial assumptions be expressed once and inherited where appropriate.
TRANSFORMATION ECONOMICS
From Estate Inventory to Transformation ARR
Atlas treats enterprise transformation as a set of concurrent technical and economic pathways rather than a flat server-count exercise. The estimator starts with structured source-state variables, applies workload-specific transformation logic, and then derives target capacity, cloud consumption, transformation effort, annual recurring revenue (ARR), and ultimately TCV and ROI. This makes the model useful well beyond a conventional lift-and-shift estimate: mainframe capacity, operating-system mix, architecture, virtualization, licensing, utilization, modernization strategy, and workload-specific conversion factors can all change the destination economics.
01
Compute Scope Variables
The $SRC.COMPUTE.* context describes the source capacity from several viewpoints at once: server and VM counts, vCPU and core quantities, memory, architecture families, virtualization platforms, and run-cost components. The hierarchy allows Atlas to begin with broad estate totals while accepting progressively more specific child values as discovery improves. Algorithms can therefore distinguish physical from virtual compute, x86 from POWER or mainframe, and VMware from Hyper-V or KVM instead of applying one undifferentiated multiplier to every server.
$SRC.COMPUTE.SERVER_COUNT$SRC.COMPUTE.VCPU$SRC.COMPUTE.CPU.AVG_UTILIZATION$SRC.COMPUTE.ARCH.*
02
Operating-System Scope Variables
The $SRC.OS.* context adds workload composition to raw compute capacity. Windows, Linux, AIX, and MIPS-associated workloads can carry counts, versions, distributions, licensing, and support characteristics. These variables matter directly to ARR because identical infrastructure footprints can have very different destination costs once Windows licensing, Linux support, platform compatibility, modernization requirements, and mainframe characteristics are introduced.
$SRC.OS.WINDOWS.COUNT$SRC.OS.LINUX.RHEL.COUNT$SRC.OS.AIX.*$SRC.OS.MIPS.TOTAL_MIPS
03
Distributed Compute ARR — 10,000 OS Instances
This example turns an OS mix into target-cloud compute ARR. A 10,000-instance estate is divided into 6,000 Linux and 4,000 Windows instances, with each population priced using its own effective hourly rate and annualized over 8,760 hours. The algorithm is intentionally composable: instance family, rightsizing factor, utilization, savings-plan assumptions, operating-system premium, and regional rate can replace the simple baseline rates as more detail becomes available.
ARRdistributed = Σ(Instance Count × Effective Hourly Rate × 8,760)
04
Mainframe Capacity — 30,000 MIPS
Mainframe capacity is kept separate from distributed server count. For a ROM example, 30,000 MIPS is converted with an explicit planning coefficient rather than hidden inside a server multiplier, then adjusted for target headroom and priced as cloud runtime. The conversion factor is deliberately exposed as a model assumption so it can be changed by workload type, measured utilization, transaction profile, batch behavior, or chosen modernization runtime.
$SRC.MF.MIPS$MODEL.MF.MIPS_PER_VCPU$MODEL.MF.HEADROOM$ARR.COMPUTE.MAINFRAME
05
Combined Compute ARR
The distributed and mainframe components are aggregated only after they have been modeled independently. In the illustrated scenario the resulting compute-only ARR is approximately $23.76M annually. This is intentionally not presented as total cloud TCV: storage, databases, backup, networking, observability, security, support, data transfer, and transformation services remain separate cost domains. Keeping these dimensions explicit prevents the estimator from disguising missing scope inside a single blended number.
$ARR.COMPUTE.TOTAL = $ARR.COMPUTE.DISTRIBUTED + $ARR.COMPUTE.MAINFRAME
06
MIPS Transformation Equation
The larger equation formalizes why Atlas is more than a lift-and-shift calculator. Source MIPS are filtered through effective utilization, workload share, migration percentage, strategy-specific transformation cost, complexity, workload-specific MIPS-to-vCPU coefficients, target headroom, and cloud runtime rates. Parallel-run costs and supporting cloud services are then added across the analysis period. The result is a model that can represent rehosting, replatforming, refactoring, rewriting, retirement, retention, and mixed mainframe outcomes without reducing the problem to “MIPS ÷ constant = instances.”
TCV = Transformation + Parallel Run + Σ(Cloud ARR + Data + Storage + Network + Security + Support + …)
07
Concurrent Transformation Pathways
Real estates do not follow one migration path. Atlas evaluates multiple pathways concurrently according to the source system: applications may be decomposed and rebuilt, platforms may move to managed services, data may be migrated and modernized, infrastructure may be consolidated and automated, and regulated workloads may follow specialized compliance paths. Shared foundations—discovery, landing zones, security, automation, observability, FinOps, governance, and organizational change—operate across all pathways. The estimator can therefore associate different technical transformations with different capacity, effort, risk, timing, and ARR consequences inside the same pursuit.
DISCOVER → CLASSIFY → TRANSFORMPATHWAY-SPECIFIC COSTCONCURRENT WAVESARR / TCV / ROI
01
Hierarchical Estate Model
The Enterprise Transformation Model represents the estate through structured contexts such as source and target environments, data centers, servers, virtual machines, operating systems, databases, storage, licenses, support, and migration characteristics. Each layer can carry global assumptions while allowing lower-level overrides when better information exists.
02
Globals & Inheritance
A core design principle is inheritance. For example, a global database storage value can provide a default, while Oracle, SQL Server, or another database type can define its own storage, license, and support values. Blank local values inherit the parent assumption instead of forcing repetitive data entry. This allows the model to start rough and become more precise as discovery improves.
03
Scenario Construction
Source-state variables can be paired with target-state variables to describe lift-and-shift, replatforming, consolidation, cloud migration, data-center exit, or hybrid scenarios. Assumptions can be changed at the appropriate level and propagated through cost and capacity calculations, enabling rapid what-if analysis without rebuilding the model.
04
Economic Layer
Technical quantities connect directly to migration effort, licensing, infrastructure, support, labor, cloud consumption, and contract value. This creates a bridge from architecture inventory to financial outputs such as annual run cost, transformation cost, savings, TCV, and ROI.
05
Long-Term Direction
The model is intended to become a canonical enterprise abstraction that Atlas can ingest, validate, compare, and explain. Over time, structured vendor catalogs and benchmark data can enrich the variables while keeping customer-specific overrides explicit and auditable.
