A migration factory on two clouds: ServiceNow CMDB and the Nutanix v4 API, moving a financial services estate onto NC2 on AWS and Google Cloud

A large financial services firm has two datacenters it wants out of. Retail and commercial banking systems, a payments hub that authorizes and settles card and account-to-account traffic, trading and risk support for the capital markets side, a general ledger and its reporting batch, and the shared services under all of it. Most of it is ESXi under vCenter. The newer clusters already run AHV. The decision is made: NC2 on AWS and NC2 on Google Cloud, with the same operating substrate in each. ServiceNow is the firm's system of record for configuration and change, and the ask is specific: don't run this as a project, run it as a factory. Every application goes through the same stages, every stage is a ServiceNow record, and the platform work is automated through the Nutanix v4 APIs, not clicked. Then, once an application has landed, a modernization suite picks it up.

This firm is a composite. It isn't any particular bank, broker or processor. I built it from public documentation, not from any customer, and every vendor and regulatory claim below links to the public page I read it on. Where a page didn't say what I needed, I say so.

A factory is a different thing from a big migration. A project asks "how do we move these 2,000 VMs?" and gets a plan. A factory asks "how do we move one application, the same way, every time?" and gets a line: the same stages, the same records, the same automated calls, the same evidence, run again for the next application on Monday. The second question is the one a regulated firm can defend, because every application's move leaves the same trail behind it. The insurer post was about one exit with a hard date. This one is about the machine you build when the exit takes years and the auditors visit every one of them.

What I checked before drawing anything

Six parts of the ask needed checking against the documentation first. Three of them changed the design.

• The v4 API covers the factory's platform work, with one version trap. Categories, VM inventory and tagging, Flow Network Security policies, protection policies and the task loop are all in the published v4 specifications at v4.1, with a minimum of Prism Central 2024.3. Recovery plans aren't: they first appear at v4.2 and need Prism Central 7.5. And protection policies live in the datapolicies namespace, not dataprotection.
• Nutanix Move has its own public API. It's a separate REST API (under /move/v2/, documented for Move 6.3.1), not part of v4, so the factory drives two Nutanix APIs, not one.
• No ready-made Nutanix to ServiceNow migration integration. ServiceNow's published spokes list has no Nutanix spoke and its Service Graph Connector list has no Nutanix connector (I couldn't read the Store). What exists is Discovery's Nutanix pattern (with v4 support), Prism Central's alert push into Event Management, and Nutanix plug-ins that put Self-Service and NDB in the service catalog. The factory's v4 calls are custom IntegrationHub actions the platform team owns.
• One Prism Central for both clouds: no. Each guide lists only Prism Centrals in the same account and availability zone (AWS) or the same region and availability zone (Google Cloud) when registering a cluster. Two clouds, at least two control planes.
• Flow Network Security: AWS yes, with Flow Virtual Networking; Google Cloud not found. That sends the payments hub's cardholder data environment to AWS.
• The modernization suite is not the same on both clouds. Nutanix Kubernetes Platform is named for both. Nutanix Database Service is documented for NC2 on AWS and Azure, not Google Cloud. NCM Self-Service and Nutanix Data Services for Kubernetes have no NC2 support statement I could find.

What makes it a financial services migration

Four themes from public texts shape the factory once the estate belongs to a regulated financial firm. I quote what they say. Mapping them to this design is mine, and it isn't legal or compliance advice: the firm's risk, compliance and audit functions own the real mapping.

Change has to be a process, with types. The FFIEC IT Examination Handbook's Change Management section (in the Architecture, Infrastructure, and Operations booklet) says policies "should categorize changes by severity, specify corresponding approval processes, and identify responsible staff." It lists the steps (request, review, approve, design and build, test, implement, verify and close) and expects a request to carry an "impact analysis to identify risks and affected systems, change time frame, and back-out plan." Then it names three kinds of change. Planned changes follow the full process. Routine changes "are generally performed frequently or regularly and follow standard procedures. They may be pre-approved." Emergency changes "should be reviewed and approved after implementation." That middle category is the factory's whole bet: a wave pattern that has run cleanly enough times becomes a routine change, pre-approved, because every instance of it is the same. The handbook also says implementation should happen "during off-peak hours or planned system outages," which is where the freeze calendar below comes from.

On the SOX side there's no single list to quote, so I won't pretend there is. The SEC's interpretive guidance for management (Release 33-8810) names "IT general control areas, such as program development, program changes, computer operations, and access to programs and data," and says automated controls often depend "upon effective IT general controls." Moving the servers that run a ledger, a reconciliation or a reporting batch is a change to the systems those controls cover. For in-scope applications, the change record, its approvals and the evidence that the system was the same afterwards are what an auditor asks to see. That's the reason the factory keeps every one in ServiceNow, attached to the change, and not in a migration tool's own database.

The inventory is a regulated artifact. The handbook's Technology Asset Inventory section says asset management procedures "should outline a process to update the technology inventories after changes to IT infrastructure or operations," and lists SOX among the risk assessments the inventory supports. New York's cybersecurity regulation, 23 NYCRR Part 500 as amended in November 2023, is more specific. Section 500.13(a) requires "a complete, accurate and documented asset inventory," tracking for each asset at least its "owner; location; classification or sensitivity; support expiration date; and recovery time objectives," and a policy for "the frequency required to update and validate" it. Under 500.22(d)(4) that requirement took effect two years after November 1, 2023, so it already applies to covered entities. A migration changes the location of every asset in the inventory. If the CMDB is the inventory, the factory has to update it as part of each wave, not after the program.

Moving to a cloud is a third-party relationship with a life cycle. The US banking agencies' Interagency Guidance on Third-Party Relationships: Risk Management (88 FR 37920, June 9, 2023) describes a life cycle of planning, due diligence and selection, contract negotiation, ongoing monitoring and termination. Planning includes "contingency plans in the event the banking organization needs to transition the activity to another third party or bring it in-house," and for critical activities "plans may be presented to and approved by a banking organization's board of directors." For a firm with EU operations, DORA (Regulation (EU) 2022/2554, applying from January 17, 2025) is blunter. Article 28(8): "For ICT services supporting critical or important functions, financial entities shall put in place exit strategies," tested and reviewed periodically. Article 28(3) adds a register of information on every ICT third-party arrangement. Article 9(4)(e) wants changes "recorded, tested, assessed, approved, implemented and verified in a controlled manner," which reads like the factory's stage list.

The FFIEC handbook's Shared Responsibilities section lists "managing and implementing controls over the hypervisor(s)" among the controls that can sit with either party. NC2 makes that concrete. The firm runs AHV and Prism Central on bare metal in its own cloud account, so the hypervisor controls are the firm's to operate, the cloud provider's side of the line is the hardware, the facility and the network underneath, and Nutanix is a third party too, through the NC2 console service that creates, resizes and terminates clusters in that account. That's a three-way split, not the two-way one of native IaaS, and the third-party file for each cloud should say so.

Segmentation decides PCI scope. The payments hub handles card data, so its cardholder data environment (CDE) is a PCI DSS assessment boundary. I couldn't read the current PCI DSS v4.x text: the PCI Security Standards Council's document library puts it behind a license click-through, and I didn't accept it, so I give no v4 requirement numbers. The council's scoping and segmentation supplement, written for v3.2, says segmentation "is not a PCI DSS requirement" but "is strongly recommended as a method that may reduce" the scope of the assessment, and that under that version "all segmentation controls must also be penetration tested at least annually." In 2024 the council announced a newer supplement covering "micro-segmentation and multi-cloud implementations." The design point holds whatever the current numbering: if the firm relies on Flow Network Security or a cloud firewall to keep the CDE small, that control is a segmentation control, and it gets tested as one.

And a practice that isn't a rule. Most financial firms freeze change around month-end and quarter-end close, and around year-end. I found no regulation that requires it; I looked in the texts above and none mentions freeze or blackout periods. It's an industry practice, and a sensible way to apply the handbook's "off-peak hours or planned system outages" and the SOX interest in the systems that produce the close. The factory treats it as calendar input, owned by the firm, not as a rule I can cite.

The estate

The source is two owned datacenters. Most of the estate is ESXi under vCenter, and the newer clusters run AHV under an on-premises Prism Central. Some things don't move in the factory at all: the mainframe, the hardware security modules (HSMs) the payments hub calls, the market data lines and the card network links. Those are "retain" dispositions, and the applications that talk to them keep talking to them over the private links, which is why address groups show up in the Flow policies below.

The targets are NC2 on AWS and NC2 on Google Cloud, with the same substrate in each and a separate control plane for each. Neither guide puts both clouds under one Prism Central. When you register a new cluster to an existing Prism Central, the NC2 on AWS guide (edition of October 7, 2026) says "the system displays only those Prism Central instances on the same account and Availability Zone as the cluster," and the NC2 on Google Cloud guide (same date) lists "only Prism Central instances that are in the same region and availability zone." The AWS guide also says, in its limitations, "you cannot register an On-premises Prism Element cluster to an NC2 Prism Central, and vice versa," while its overview says NC2 on AWS "supports both existing on-premises Prism Central instance or Prism Central instance deployed on NC2 on AWS." The two read against each other. I design on the limitation, because it's the stricter reading, and that's a question for Nutanix before wave 0. So the factory talks to at least three Prism Centrals during the program (the on-premises one and one per cloud) and to two when it's done. That's fine for automation, because the v4 calls are the same against each one. It's a real cost for operations, which the cost section comes back to.

Which cloud an application lands in is decided at stage 3, with the disposition, and it's recorded on the service instance. The rules are the insurer post's: follow the data and the services the application already uses, keep chatty groups together, land a move group (and its subnets) in one cloud. Two rules are specific to this firm. Anything whose plan includes Nutanix Database Service, and anything that needs per-VM segmentation inside the cluster (the payments hub's CDE), lands on AWS, for reasons the next sections give. And no application is split across the clouds: the Nutanix Disaster Recovery guide labels its NC2 to NC2 recovery plan row "(Same cloud)," and I found no cross-cloud row.

The factory, stage by stage

The line has eight stages, and the rule that makes it a factory is in the diagram's first sentence: every stage is a state on a ServiceNow record, and nothing moves to the next stage unless the record changes state. Each state change leaves an approver, a time and an attachment. When an examiner or an auditor asks how a given application moved, the answer is one record and its history, the same shape for the first application and the four-hundredth.

1. Intake. The unit of work is a service instance, not a VM. If it isn't in the CMDB as a service instance with an owner, a tier and a recovery time objective, it doesn't enter the line. That's the same rule the insurer post used ("if a VM isn't a CI in an application service, it doesn't get a wave"), and in this industry it's also the 500.13 inventory doing its job.
2. Discover. Discovery and Service Mapping build the dependency map, and the application owner certifies it. Uncertified maps don't pass gate G1. The insurer post covers the method (top-down plus traffic-based mapping, owner certification, firewall logs as a second check), and nothing about it changes here.
3. Assess and disposition. One disposition per service instance, recorded on the record: rehost (same VM, onto AHV), replatform (same application, a managed platform under it, such as a database service), refactor (rebuilt, usually onto Kubernetes), retire (archived and switched off), or retain (stays where it is, usually because it's tied to something that doesn't move, like a mainframe or a hardware security module). The factory line only runs rehost. Retire runs as its own short change. Replatform and refactor go to the second lane after a rehost, not instead of one, unless the application owner can show the rebuilt version is ready before the datacenter needs to be empty.
4. Plan waves. A move group is a set of service instances closed over their chatty dependencies and their subnets. A wave is a set of move groups plus a window. The wave gets its change request here, with the back-out plan the FFIEC handbook asks for written into it.
5. Migrate. Two paths, picked by the source. ESXi VMs move with Nutanix Move. VMs already on AHV move by replication: a protection policy and a recovery plan to the NC2 cluster, then a planned failover. Both are covered below.
6. Validate. The smoke test is the application owner's. The platform checks are the factory's, and they're automated: is every VM in the move group running on the target cluster, does each carry its categories, is its Flow Network Security policy in the expected state, is its protection policy taking recovery points. All of it is v4 reads, and the results go on the change record.
7. Hand off. The CIs now point at NC2, the owner accepts, operations accepts, the change closes.
8. Modernize. Not part of the line. It's the second lane, after landing, on the application team's schedule.

A modeling note. In CSDM v5, ServiceNow renamed the application service. The CSDM definitions now say "Service instance (called application service before CSDM v5): A service type that is a logical representation of a deployed application stack," and the business application "represents all software and infrastructure environments (dev, test, prod) that are configured to provide functionality." The factory's unit of work is the service instance: the deployed thing that has CIs, runs somewhere and moves. The business application is where ownership and data classification live. I keep the category key AppService because that's what most teams still call it.

Two ways in: Move for ESXi, replication for AHV

Stage 5 has two paths, and the factory picks one per move group from the CMDB's record of the source hypervisor.

ESXi sources go through Nutanix Move. The Move 6.3 user guide lists "VMware ESXi to NC2 on AWS" and "VMware ESXi to NC2 on Google Cloud (formerly Google Cloud Platform or GCP)" among its migration paths. The insurer post covers Move's model in detail (seeding, the snapshot trap when Move enables CBT, test migrations, the cutover sequence, the parallelism limits), and all of it applies here. What's new is that Move has its own REST API, so the factory can drive it too. The Move API reference on nutanix.dev, "Nutanix Move REST APIs," says "this document covers APIs that are available in Move-6.3.1." Its paths are under /move/v2/, with a bearer token from POST /move/v2/token. Providers (the ESXi source and the Nutanix target; the examples show provider types such as ESXI and AOS) are under /move/v2/providers, plans under /move/v2/plans, with prepare, readiness, start, suspend, resume and cancel as plan actions. Cutover is a per-VM action, not a plan action: POST /move/v2/plans/{id}/workloads/{wid}/action, whose documented actions include test, cutover and abort. That fits the factory well. The plan is created and seeding starts from the stage 4 change task; the test migration and the cutover are separate change tasks in the window, each with its result attached.

Two Move details go into the factory's code. On Google Cloud, the ESXi to NC2 page in the Move guide sends readers to KB-20812 for NC2 on Google Cloud, and that KB says its manual workflow is "valid only for Nutanix Move versions 6.0.1 through 6.1.3. From Move 6.2.0 onwards, the Move appliance will take care of this workflow automatically." Pin Move at 6.3 or later there. And Move is a separate product with a separate API version (the reference is at 2.6.0), so it gets its own pin in the factory's code, like the v4 namespaces.

AHV sources move by replication. The newer clusters don't need Move: their VMs can reach NC2 by Nutanix Disaster Recovery, the same mechanism the firm will use for DR afterwards. The DR guide documents on-premises to NC2 on AWS ("using either the AWS VPN or AWS Direct Connect") and on-premises to NC2 on Google Cloud ("Starting from Prism Central 7.3.1.1 ... you can now create a new remote site in the on-premises Nutanix cluster for the new cluster on Google Cloud"). It also says "synchronous replication schedule is not supported for DR solution between on-premises AZ and NC2 AZ," so the replication is asynchronous or NearSync.

In v4 terms, that path is a protection policy keyed on the move group's category, a recovery plan whose stage selects the same category (the v4.2 RecoveryPlan stage has a categoryExtIds field), a validate, a test-failover, and then a planned-failover, which the specification describes as: "VMs are powered off on the source before migrating it to the target domain manager." That's a migration with a rehearsal and a way back (the DR guide describes a planned failover on the NC2 side to move workloads back on premises), and it leaves the application with DR already configured on arrival. It also requires Prism Central 7.5 on both sides for the v4.2 recovery plan calls, which is one more reason the version floor is a wave 0 decision.

One key across two systems

A factory that spans ServiceNow and two Prism Centrals needs one key that both sides understand. VM names won't do: they get reused, renamed and mistyped. The key here is the Prism Central category, a key:value pair, and ServiceNow owns its values.

Categories are built for this. In the v4 prism specification, POST /prism/v4.1/config/categories "creates a category with a given key and value pair," and the category object's associations field summarizes the counts of the resources that carry it. The VM object in the vmm specification has a categories list of up to 256 references, set on a landed VM with the associate-categories action. And the rest of the platform selects by category, not by name. A protection policy's categoryIds field is, in the specification's words, "the list of external identifiers of categories that must be added to the protection policy. This policy will protect any VM or volume group associated with this category." A Flow Network Security policy's securedGroups are "the categories in the secured groups in the Network Security Policy." So once a VM carries AppService:pay-auth-prod, its backup, its recovery plan and its microsegmentation follow from that one tag.

Four rules keep the key honest. ServiceNow creates the category values from the CMDB, and nobody types them by hand in Prism Central. A VM that lands without an AppService category fails validation. A Wave value is retired when the wave closes, never reused. And a DataClass value, such as the payments hub's pci-cde, decides which Flow subnets and policies a VM is allowed to land in. That last one is how the PCI boundary survives the move: the segment is assigned from the CMDB's data classification, not remembered by whoever builds the subnet.

The Nutanix v4 API in the factory

Everything in this section comes from the v4 OpenAPI specifications Nutanix publishes on developers.nutanix.com, which I downloaded for each namespace on October 7, 2026, and the Nutanix API User Guide. I haven't run this sequence against an NC2 cluster, and the paths, minimum versions and field names are the specification's, not mine.

The developer portal lists the v4 namespaces with a line each. Seven do the factory's work:

• prism, which the portal describes as "Manage Tasks, Category Associations and Submit Batch Operations": categories and the task loop.
• vmm, "Manage the life-cycle of virtual machines hosted on Nutanix": the inventory read and the category association.
• microseg, listed as Flow Management: "Manage Network Security Policy configuration on Nutanix clusters. Configure and get details of service-groups, address-groups, ID based security."
• datapolicies, "Manage Policies for Disaster Recovery and Storage": protection policies and recovery plans.
• dataprotection: recovery points, and the recovery plan actions (validate, test failover, planned failover).
• monitoring, "Manage Alerts, Alert policies, Events and Audits": the audit trail.
• lifecycle, "Manage Infrastructure, Software and Firmware Upgrades": platform readiness before a wave.

Two things in that list are easy to get wrong. Protection policies are in datapolicies, not dataprotection. The path is POST /datapolicies/v4.1/config/protection-policies. dataprotection holds recovery points and the recovery plan operations. Recovery plans don't exist at v4.1. They first appear at v4.2: the plan itself at POST /datapolicies/v4.2/config/recovery-plans, and the actions at POST /dataprotection/v4.2/operations/recovery-plans/{recoveryPlanExtId}/$actions/validate, .../test-failover, .../planned-failover and .../unplanned-failover. Every one of those lists a minimum of Prism Central 7.5 and Prism Element 7.5. Everything else the factory calls lists Prism Central 2024.3 (the LCM operations list 7.3). So automating DR and the replication path raises the estate's version floor, and that's a platform decision to make before wave 0, not a surprise at wave 12.

The conventions are the same in every namespace, and the day-one post walks through them with curl: Basic auth or an API key, an NTNX-Request-Id UUID that the API User Guide calls "mandatory on nearly all POST, PUT and DELETE requests" and uses "as an idempotence token for safely retrying requests," If-Match with the object's ETag on actions against an existing object, and a 202 with a task on every write. The task is the factory's heartbeat. GET /prism/v4.1/config/tasks/{extId} returns a status (QUEUED, RUNNING, CANCELING, SUCCEEDED, FAILED, CANCELED, SUSPENDED), the entitiesAffected, and errorMessages when it fails. Every automated change task in ServiceNow ends the same way: poll the task, attach the final task object to the change record, and fail the change task if the status is anything but SUCCEEDED.

Here's what each stage calls, all on https://{prism-central}:9440/api:

SDKs and batches. Each namespace publishes a client in Python, Java, Go and JavaScript; on PyPI the Python ones are named per namespace, such as ntnx-vmm-py-client and ntnx-microseg-py-client. The API User Guide says "where possible, Nutanix recommends using the Nutanix v4 APIs via the new language-specific SDKs," and that the SDKs add the request identifier to each request for you. A ServiceNow REST step can still call the endpoints directly, and for a handful of calls per change task that's simpler. For tagging a whole move group at once, the prism namespace has POST /prism/v4.1/operations/$actions/batch, and the guide says "up to 500 entity actions can be included in a single batch request."

What isn't v4. The NC2 console API that creates clusters is its own product API, as the KB page on this site covers, and so is Move. Move's API is covered with the migration paths above. Neither belongs to the v4 namespaces, and each gets its own version pin.

Rate limits. The API User Guide says "rate limits are dictated by the Prism Central type and configuration," and its table runs from 30 requests per second for an X-Small Prism Central to 80 for an Extra Large one. A factory that runs several waves' validation at once against one Prism Central shares that budget, so the integration polls tasks at an interval, not in a tight loop, and uses batches for bulk tagging.

From dependency map to Flow Network Security policy

The dependency map does double duty. It decides the move groups, and it's also the first draft of the application's microsegmentation policy, because a certified list of "who talks to this application, on which port" is exactly what an allow-list policy needs. The factory turns one into the other mechanically.

The microseg specification gives the pieces. A policy has a type (QUARANTINE, ISOLATION, APPLICATION or SHAREDSERVICE), a state (SAVE, MONITOR or ENFORCE; the spec describes it as "whether the policy is applied or monitored"), securedGroups given as categories, and rules. An application rule (ApplicationRuleSpec) names a source or destination by category (srcCategoryReferences, destCategoryReferences), by address group (srcAddressGroupReferences) or by subnet, and the traffic by service group or by explicit TCP, UDP and ICMP services. An INTRA_GROUP rule covers traffic inside the secured group. So the translation is:

• The service instance's AppService category is the secured group.
• Every certified inbound caller that has landed on NC2 becomes a source category. Every caller that hasn't (still in the datacenter, or never moving, such as the HSMs or the mainframe) becomes an address group.
• Every port in the map becomes a service group, reused across applications.
• Web-to-app traffic inside the application is an intra-group rule.

The policy is created in MONITOR. The Flow Network Security guide says that in that state "the application continues to receive all traffic even from the disallowed source, but disallowed traffic is highlighted on the monitoring page. Traffic is not blocked until the policy is applied." Each highlighted flow is either a gap in the map (fix the CMDB, add the rule, recertify) or a flow that shouldn't exist (open an incident). When the observation window passes clean, a change task flips the state to ENFORCE, with If-Match on the policy's ETag. For the payments hub, the policy that encloses DataClass:pci-cde is a segmentation control in the PCI sense, so it goes on the list of controls the firm's segmentation testing covers.

Where this works is decided by the clouds section below: on NC2 on AWS with Flow Virtual Networking, yes; on NC2 on Google Cloud, not documented, so there the same certified map becomes hub firewall rules instead, and the change task that would flip a Flow policy to ENFORCE becomes a firewall rule review.

Change as the conveyor belt

The factory runs on ServiceNow change management, and the documentation already has the three pieces it needs.

Change types. ServiceNow's change types page defines a standard change as "a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction," a normal change as "any service change that is not a standard change or an emergency change," and an emergency change as one that "must be implemented as soon as possible." Normal changes go to the change advisory board (CAB); standard changes don't need it. The standard change catalog describes standard changes as "pre-approved, low risk changes with a proven history of success," and "uses a proposal process to control which changes become available in the standard change catalog." That's the same idea as the FFIEC handbook's routine changes that "may be pre-approved," in ServiceNow's words.

So the factory starts every wave pattern as a normal change, with CAB. When a pattern (say, rehosting a low-tier application with no PCI data) has run cleanly enough times, the platform team proposes it as a standard change: the same change tasks, the same automated calls, the same evidence, without a CAB meeting per wave. How many clean runs is "enough" is the firm's change policy, not mine. Some patterns never graduate: anything in the cardholder data environment, and anything whose application has a recovery test in the change, stay normal changes, because a human should look at those every time. A failed wave sends its pattern back to CAB. The progression is my design. The mechanism is ServiceNow's.

Blackout windows. ServiceNow's blackout and maintenance schedules work exactly as the freeze calendar needs: "Blackout windows specify times during which normal change activity should not be scheduled. Maintenance windows specify times during which change requests should be scheduled." Conflict detection "identifies potential scheduling conflicts for a change request based on the configuration items," and one of its reasons is "the CI is in a blackout window." So the month-end, quarter-end and year-end freezes become blackout schedules on the services they protect, and a wave booked into one gets flagged by the schedule, not by someone remembering the calendar. The dates are the firm's.

The automation. ServiceNow's flow tooling (documented today under Workflow Studio; a flow "consists of a trigger and one or more actions") calls external APIs through IntegrationHub, which the IntegrationHub overview notes needs "a separate subscription." The pieces the factory uses are documented on the IntegrationHub overview of capabilities: spokes for third-party APIs, custom integrations "using a REST step or a Script step," and actions delegated "to a MID Server in your network," for example "actions that use the PowerShell step or REST step." The REST step sends "an outbound REST web service request to an external system," and connection and credential aliases keep the Prism Central and Move credentials out of the flows themselves.

There's no Nutanix spoke in ServiceNow's published spokes list, and I couldn't read the ServiceNow Store, so the factory builds its own actions: one custom action per v4 call it uses, each one a REST step through the MID Server in the right cloud, plus one shared "poll task until done" action. That's a dozen actions, owned and versioned by the platform team. Each change task in the wave's change request calls one of them and attaches the final task object.

Writing back to the CMDB. Two routes, and the factory uses both. ServiceNow Discovery's Nutanix pattern discovers Prism Central and Prism Element (it names "Nutanix Prism Central version 2024.3.1.8 or Nutanix Prism Element 7.0.1.6"), says "starting with version 1.29.0, Discovery and Service Mapping Patterns supports Nutanix v4 discovery," and from pattern version 1.31.0 its VM event pattern supports v4 too, with "Prism Central ... at least version 7.3." It asks for "a dedicated MID Server with network access to Prism Element and Prism Central." I didn't find it documented for NC2 by name, so pointing it at each cloud's Prism Central is a wave 0 test, as the insurer post said. The second route is the factory's own read-back: after a wave, the validation step reads the VMs and their categories through v4 and writes the facts Discovery doesn't know (move group, wave, the change that moved them) through ServiceNow's Identification and Reconciliation Engine, which says that for "third-party data sources, you can leverage REST or scriptable IRE APIs to perform identification and reconciliation," and "prevents duplicate CIs by uniquely identifying CIs." I found no Service Graph Connector for Nutanix in ServiceNow's published list.

What Nutanix itself ships for ServiceNow. Less than you might expect, and none of it is a migration integration. Prism Central has an X-Play action, Send to ServiceNow, that "pushes the Prism Central alerts to ServiceNow to be processed by the ServiceNow event management pipeline": useful for hypercare, after a wave. The NCM Self-Service plug-in for ServiceNow is current (its 1.7.3 release notes, May 2026, say it "is also compatible with Zurich version of ServiceNow"), and it exposes Self-Service blueprints and runbooks as catalog items, which belongs to the second lane, not the factory. An NDB plug-in for ServiceNow "enables you to use NDB from the ServiceNow platform as a service catalog item"; its guide was last updated in September 2024, and I can't say whether it's current. Nutanix's old ServiceNow repository on GitHub is archived and says its integrations "are not production-grade."

The two clouds: same calls, different networks

The factory's automation is the same on both sides. The network underneath each cluster isn't, and the platform team builds it once per cloud, before wave 0.

NC2 on AWS. Flow Virtual Networking is optional on AWS ("as an alternative to AHV Networking, NC2 on AWS now supports Flow Virtual Networking," says the guide), it can only be turned on when the cluster is created, and this design turns it on, for two reasons from the documentation. First, per-VM segmentation: the NC2 on AWS release notes say "NC2 on AWS clusters with Flow Virtual Networking enabled and running AOS 6.8 or higher support Flow Network Security (FNS) Next-Gen with the FNS version 4.1.0 or higher," and the Flow Network Security 7.6 guide says "Flow Network Security Next-Gen in a VPC environment supports NC2 on AWS," while "Flow Network Security Next-Gen with network controller-managed VLAN does not support NC2 on AWS." Second, NDB on NC2 needs a no-NAT overlay subnet in a transit VPC. One trade-off to write down: the AWS guide says "Flow Virtual Networking does not work when you use the Cluster Protect feature," so cluster-level protection to S3 isn't available on these clusters, and the application-level protection policies carry that job.

The routing hub is AWS Transit Gateway, which AWS describes as "a network transit hub used to interconnect virtual private clouds (VPCs) and on-premises networks." The NC2 guide has a procedure for it, Configuring No-NAT Traffic Flow Through AWS Transit Gateway, with the reasoning spelled out: "AWS Transit Gateway supports no-NAT reachability from any other site, as ERP prefixes are non-AWS native," and ERPs (externally routable prefixes, the overlay ranges routed without NAT) are "advertised in the AWS Transit Gateway route tables." The steps are to attach the VPCs, add static routes in the Transit Gateway route table where propagation doesn't cover them, add routes for the ERP prefixes in each VPC route table ("else, it will take the default route to the internet gateway"), and open the security groups. For inspection, the firm's firewall sits in an inspection VPC attached to the same Transit Gateway; AWS's appliance mode exists for exactly that case, "if you plan to configure a stateful network appliance in your VPC." The Nutanix guide doesn't describe an inspection VPC, so that part is AWS's pattern applied by me, and the first wave 0 test.

NC2 on Google Cloud. Everything the insurer post found applies unchanged, and I won't repeat the detail. Flow Virtual Networking is the only networking model the guide documents. No-NAT overlay prefixes become static routes in the VPC, one per ERP, pointing at an internal passthrough load balancer. That's why the insurer post's hub is a VPC peering hub with the firewall in it, not Network Connectivity Center: a design joined from Google's and Palo Alto's documentation and applied to NC2 by me, to validate, not a Nutanix reference. The datacenter connects through Cloud VPN or Cloud Interconnect. And Flow Network Security doesn't appear in the NC2 on Google Cloud guide or release notes, and the Flow Network Security 7.6 guide's NC2 section names only AWS and Azure. On this side the hub firewall is the segmentation control until Nutanix says otherwise, which is why the CDE lands on AWS.

The MID Servers. ServiceNow reaches each Prism Central from a MID Server inside that cloud's network, so the factory's credentials and traffic to the v4 API never cross the internet. The Discovery pattern asks for exactly that ("a dedicated MID Server with network access to Prism Element and Prism Central"), and IntegrationHub's REST step can run through a MID Server, so one MID Server group per cloud serves both Discovery and the factory's calls. The Move appliance sits on the source side (the Move guide's recommendation for on-premises to NC2 over a WAN: "deploy Nutanix Move on the source environment") and is reached from the datacenter MID Servers.

The second lane: modernization after the landing

The ask was a modernization suite after the rehost, and the honest version of that suite is narrower than the product list. Here's what the public documentation supports on each cloud, as of October 7, 2026.

• Nutanix Kubernetes Platform (NKP) is the refactor target on both clouds. The NKP 2.18 guide says "the Nutanix environment must be either on-premises or hosted on one of the public clouds, such as NC2 Azure, NC2 AWS, or NC2 GCP." That's a prerequisite line, not a validation matrix, but it names both clouds.
• Nutanix Database Service (NDB) is the replatform target for the database fleet, on AWS only. The NDB 2.11 guide describes "operations such as database registration, provisioning, cloning, patching," and says "NDB supports Nutanix Cloud Clusters (NC2) on AWS and Azure for all database engines." Google Cloud isn't in the guide. Database replatforms land on AWS, or wait.
• NCM Self-Service (blueprints and runbooks for application teams, per its 4.4.0.1 guide) has no NC2 support statement I could find, and the Nutanix Cloud Manager 2.1 guide says "Nutanix has not yet certified Next-Gen NCM 2.1 to run on a Nutanix Cloud Infrastructure - Compute (NCI-C) cluster or Nutanix Cloud Clusters (NC2)." Not a dependency until that changes.
• Nutanix Data Services for Kubernetes (NDK): the NDK 2.3 guide doesn't mention NC2. Not confirmed.
• Nutanix Unified Storage: the Objects 5.4 guide covers NC2 on AWS with a limit ("Nutanix Cloud Clusters (NC2) only support single-node deployments"). I found nothing equivalent for Google Cloud.

I couldn't open the NC2 compatibility matrix on the Nutanix portal (it asks for a login), and that matrix may say more than the guides. The rule I'd run the lane on: nothing goes into the second lane on a product the public docs don't list for that cloud until Nutanix confirms it in writing.

The lane's other rules are about risk, not products. One application per change. The VM being replaced stays in place until the new version has run a full business cycle, which for anything touching the ledger means at least one month-end close. And the lane gets its own change records, separate from the factory's, so a refactor that slips never holds up a wave.

The evidence map

The diagram is the regulatory section turned around: for each text, what it asks for, and which record in the factory holds the answer. Two rows deserve a sentence each. The exit row isn't a document written once: the firm's exit plan for each cloud is the factory itself, pointed the other way, and testing it means running one low-tier application back out (to the other cloud or to owned hardware) before the program ends. And the backup row is only satisfied by a test. A protection policy taking recovery points proves the schedule works. The validated recovery plan and its test failover, attached to the change, prove a restore does, which is what 23 NYCRR 500.16(d) ("ability to restore its critical data and information systems from backups," tested at least annually) and DORA Article 12 ask about.

What it costs the architecture

The exit path is the strongest part of the design and the reason to accept the rest. The workloads stay VMs on AHV in both clouds, the policies and categories live in Prism Central rather than in either cloud's native constructs, and the factory that moved them in is the same factory that can move them out, to the other cloud or back to owned hardware. That's what DORA's Article 28(8) and the interagency guidance's termination stage are asking a firm to be able to show, and here it's a working line with a history, not a slide. What doesn't port is the network around each cluster: the AWS Transit Gateway design and the Google Cloud hub each belong to their own cloud, and moving between them is a network project.

The integration is the new tech debt. Every v4 namespace is versioned on its own, and the factory pins one version per namespace (v4.1, with v4.2 for recovery plans). Raising a pin is a change with its own test, on the factory's own code, not something that happens because a Prism Central upgrade made a newer version available. Leave it unowned and the factory quietly becomes the thing nobody dares to touch, which is the opposite of the point.

What this does not claim

• Not a real firm, and not a tested factory. The firm is a composite, not any particular bank, broker or processor, and the design is built from public documentation. I haven't run these calls against an NC2 cluster or these flows in a ServiceNow instance.
• Not legal, compliance or audit advice. I quote the FFIEC handbook, 23 NYCRR 500, the interagency guidance, DORA and the SEC's guidance. Mapping them to this design is mine, and the firm's compliance, risk and internal audit functions own the real mapping.
• Not a PCI DSS v4 citation. The current standard sits behind a license click-through I didn't accept. The segmentation guidance I quote was written for v3.2.
• Not a regulatory source for change freezes. Month-end, quarter-end and year-end freezes are industry practice. I found no rule that requires them.
• Not one Prism Central, and not cross-cloud DR. Each cloud has its own, and I found no documented DR path between NC2 on AWS and NC2 on Google Cloud. The AWS guide is inconsistent on whether an on-premises Prism Central can manage NC2 on AWS; I design on its limitation, pending Nutanix.
• Not a Nutanix-documented Google Cloud hub. The peering hub is the insurer post's design, joined from Google and Palo Alto documentation, and still a validation item.
• Not Flow Network Security on NC2 on Google Cloud. Not found in public documentation, not ruled out either. On AWS it's documented with Flow Virtual Networking, not on basic VLAN networking with FNS 7.6.
• Not the full modernization suite on both clouds. NKP is named for both. NDB is documented for NC2 on AWS, not Google Cloud. NCM Self-Service and NDK have no NC2 support statement I found, and I couldn't open the login-gated compatibility matrix.
• Not endpoints from memory. Every v4 path, field and minimum version here is from the specifications I downloaded on October 7, 2026, and the Move paths are from the Move API reference for 6.3.1. Pins move; re-read them before you write code.
• Not an inspection VPC documented by Nutanix. The Transit Gateway procedure is Nutanix's. The inspection VPC with appliance mode is AWS's pattern, applied by me.
• Not a Nutanix-supplied migration integration for ServiceNow. None is documented. The actions here are custom, built on IntegrationHub, and the firm owns them.
• Not a guarantee that Discovery's Nutanix pattern works on NC2. It isn't documented for NC2 by name. It's a wave 0 test.
• Not modernization inside the factory. The line rehosts. Refactoring and replatforming are the second lane, one application at a time.

Sources (all read October 7, 2026): Nutanix, v4 OpenAPI specifications for the prism, vmm, microseg, datapolicies (v4.1 and v4.2), dataprotection (v4.1 and v4.2), monitoring, lifecycle, networking and clustermgmt namespaces, downloaded from the developers.nutanix.com API reference, and the Nutanix API User Guide (request identifiers, batches, rate limits); PyPI, ntnx-vmm-py-client and ntnx-microseg-py-client; Nutanix, Move REST API reference (Move 6.3.1, API 2.6.0), Move 6.3 User Guide (migration paths, deployment recommendations) and KB-20812; Nutanix, NC2 on AWS Deployment and User Guide, edition of October 7, 2026 (Prism Central registration, Flow Virtual Networking, Configuring No-NAT Traffic Flow Through AWS Transit Gateway, Cluster Protect, limitations) and NC2 on AWS release notes; Nutanix, NC2 on Google Cloud Deployment and User Guide, edition of October 7, 2026, and release notes; Nutanix, Disaster Recovery Guide, pc.7.6 (on-premises to NC2 on AWS and Google Cloud, NC2 to NC2, replication limits); Nutanix, Flow Network Security 7.6 guide and its Applying an Application Policy page; Nutanix, NKP 2.18, NDB 2.11, NCM Self-Service 4.4.0.1, NCM 2.1, NDK 2.3 and Objects 5.4 guides; Nutanix, Send to ServiceNow (Intelligent Operations, pc.7.5), NDB ServiceNow plug-in 2.0, the NCM Self-Service plug-in for ServiceNow and its 1.7.3 release notes, and the archived nutanix/ServiceNow repository; ServiceNow (Zurich), CSDM term definitions, Service Mapping overview, Nutanix discovery pattern, change types, standard change catalog, blackout and maintenance schedules, conflict detection, IntegrationHub, exploring IntegrationHub, REST step, connections and credentials, flow architecture, spokes list, Identification and Reconciliation Engine and available Service Graph Connectors; AWS, What is AWS Transit Gateway and appliance mode; FFIEC IT Examination Handbook, Architecture, Infrastructure, and Operations booklet: III.D.1 Change Management, III.B.1 Technology Asset Inventory and VII.A.4 Shared Responsibilities; Board of Governors of the Federal Reserve System, FDIC and OCC, Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920; New York State Department of Financial Services, 23 NYCRR Part 500 (the DFS-hosted compilation of the regulation as amended, which labels itself not an official version; 500.11, 500.13, 500.16, 500.22); EUR-Lex, Regulation (EU) 2022/2554 (DORA) (Articles 9, 12, 28, 64); SEC, Release 33-8810, interpretive guidance for management on internal control over financial reporting; PCI Security Standards Council, Information Supplement: PCI DSS Scoping and Segmentation (written for v3.2) and the 2024 announcement of the newer supplement.