Cloud Modernization & Legacy System Migration
Cloud migration is fifteen years old as a discipline. The patterns are well understood, the failure modes are well documented, and the economics are still routinely misunderstood. Johnson Intelligence Group's cloud practice exists to help government agencies, regulated enterprises, and federal contractors get the structural decisions right: which workloads belong on which platform, in what sequence, with which authorization path, and at what total cost of ownership over the next three to five years.
Scope of practice
We work across AWS, Azure, and Google Cloud. We are platform-agnostic in advisory engagements: the right cloud is the cloud that fits the workload, the security posture, the existing operational team, and the procurement vehicles available to the client. In some engagements that means consolidating to a single cloud. In others it means a defended multi-cloud or hybrid architecture. We help clients reason through the decision rather than apply a default answer.
For government clients, we operate inside FedRAMP and StateRAMP boundaries: AWS GovCloud (US), Azure Government, GCP Assured Workloads. For enterprise clients, we work in commercial regions while attending to data residency, data sovereignty, and any regional regulatory constraints (e.g., EU GDPR, Canadian PIPEDA, state-specific privacy laws).
Assessment methodology
Most engagements begin with an assessment. We have refined an assessment methodology that produces written, decision-grade findings in 4 to 8 weeks depending on portfolio size.
Application portfolio inventory. Every running workload, its dependencies, its operational criticality, its change velocity, its license footprint, its operational team, its current hosting cost. We do not accept the client's existing inventory at face value; we walk it.
Workload archetype classification. Each workload is classified by archetype: customer-facing transactional, internal back-office transactional, batch and analytics, data warehouse, identity and authentication, document management, integration / ESB, file shares and unstructured storage, and so on. Archetypes drive migration pattern recommendations.
Migration pattern recommendation per workload. Using the 6Rs framework (rehost, replatform, refactor, repurchase, retire, retain) plus a hybrid pattern when warranted. Each recommendation is scored against effort, risk, three-year total cost of ownership, and operational fit.
Sequencing. Migration order in 6, 12, 18, and 24 month windows. Sequencing reflects the workloads that retire fastest with the smallest risk, the dependencies between workloads, and the procurement and budget cycle the client lives in.
Authorization path. For SaaS providers and government workloads, the authorization roadmap (FedRAMP, StateRAMP, IL4 / IL5 where applicable). Path selected, 3PAO criteria, document-readiness assessment, timeline.
Cost model. Three-year total cost of ownership with on-prem baseline, target-state cloud operating cost (with savings plans / committed-use discounts modeled), and migration cost. Ranges, not point estimates. Sensitivities called out.
Migration patterns: the 6Rs
We are explicit about which pattern fits which workload. There is no honor in refactoring everything, and there is no economy in lifting and shifting everything. The framework is from AWS originally and has held up well across all three major clouds.
Rehost (lift-and-shift). Move the workload as-is to cloud infrastructure. Fastest, lowest risk on the migration itself, lowest reward on operating cost. Appropriate for workloads with short remaining useful life, workloads where the application team has limited cloud-native expertise, or workloads being moved as part of a forced data center exit.
Replatform (lift, tinker, shift). Move the workload with targeted changes that improve operating fit (e.g., move from a self-managed database to a managed database service, swap a self-managed message queue for a managed equivalent). Most workloads land here. Better operating economics than rehost without the cost or risk of full refactoring.
Refactor (re-architect). Substantially redesign the workload for cloud-native patterns. Appropriate for workloads with long expected useful life, high change velocity, scale challenges, or business model changes that the legacy architecture cannot support. Highest cost, highest reward.
Repurchase. Replace the legacy workload with a SaaS equivalent. Appropriate for commodity workloads (CRM, HR, payroll, IT service management) where building or hosting your own version is not a strategic differentiator.
Retire. Some legacy systems should not be migrated, they should be retired. Most application portfolios contain 10–30 percent retire candidates: shadow systems no one owns, redundant systems consolidated by predecessor mergers, systems that no longer have active users.
Retain. Some workloads stay where they are. Mainframe-resident workloads with limited remaining useful life, workloads with regulatory or contractual constraints that pin them to specific facilities, workloads where the cloud cost-benefit is genuinely negative. Retain is a respectable answer.
Legacy system inventory and triage
The hardest part of most government and enterprise migrations is not the cloud side, it is the legacy side. Twenty-year-old systems often have no current owner. Documentation is missing or wrong. The original developers have retired. The interfaces consume undocumented data formats from systems that no one has logged into in five years.
Our legacy inventory practice is structured around three principles. First, walk the system rather than accept the existing inventory. Second, capture institutional knowledge before the people leave. Third, name a retirement order that delivers operational pain relief early so the program builds political momentum.
Cost optimization after migration
Most cloud migrations finish over their target operating budget. The reason is structural: enterprise IT teams know how to size on-prem hardware (over-provision once and run for five years), but cloud demands continuous right-sizing. Without a discipline for it, costs creep. Our engagements often include a post-migration cost optimization workstream: monthly cost reviews, savings plan and committed-use discount restructuring, right-sizing of compute and storage, archive-tier migration for cold data, and identification of workloads where on-prem or co-location economics still make sense.
Authorization paths: FedRAMP, StateRAMP, IL4 / IL5
For SaaS providers selling to federal agencies, FedRAMP is the authorization framework. Two paths exist: JAB (Joint Authorization Board) authorization, and Agency-Authorized. JAB is fewer authorizations available per year but produces a single authorization that any agency can leverage; Agency-Authorized is more readily available but binds the SaaS provider to the sponsoring agency. We advise clients on path selection based on their go-to-market plan, expected agency portfolio, and timeline.
For SaaS providers selling to state agencies, StateRAMP applies. The control set is FedRAMP-derived, which means a SaaS provider already authorized at FedRAMP Moderate has substantial reciprocity into StateRAMP. We help clients structure the program so that one assessment cycle satisfies multiple authorizations.
For DoD and defense-adjacent workloads, the Impact Levels (IL2, IL4, IL5, IL6) drive enclave selection (AWS GovCloud, Azure Government, IL5 zones). We advise on path selection, but we do not perform 3PAO assessments ourselves; we coordinate with assessors clients select.
Data center exits
For clients exiting one or more data centers, we run the program-management work that keeps the schedule, the network re-architecture, the license transfer, the operational handoff, and the legacy-system retirement decisions in alignment. Data center exits are program-management problems wearing a technology costume, and they require senior coordination across procurement, real estate, network, identity, and applications.
Want to engage? Request a capability statement and we will respond within one business day.