One of the most routine encountered cases of software migration to the cloud is the migration of entire Kubernetes workload. As an ecosystem of its own supporting state reconciliation of resources for applications, workflows, orchestrations, and data store managers. As an instance of a resource type in the public cloud, it is a unit that lends itself to the management from the public cloud console. One of the management activities of this resource is its move from one location to another or one network to another. When switching just the network integration for outbound traffic for this network, it might be tempting to think of it as a property change of a resource that amounts to in-place update. But this is just the tip of the iceberg. Different methodologies and formulae for estimation although applicable to many scenarios do not apply to this case-study without further investigation.

In this case, the instance has a default node pool and many additional node pools that may still be referencing the old network even with directive to switch to new network. They also happen to refer to additional storage accounts for facilitating the creation of persistent volumes as key vaults for storing secrets. If these satellite resources are also restricting traffic to private planes, then networking and authentication must both be enabled from the new network.

The infrastructure changes for this might also not be straight forward single-pass and require iterative maneuvers to make incremental progress. This is specifically the case when the IaC compiler encounters multiple other resources and detect changes in them the path of minimal changes to the infrastructure will imply the lowest cost and this works very well if we can wipe clean and create with the same specifications as earlier but with the new network.

Thus, estimation of infrastructure is heavily dependent on what the resource needs, the changes being made to it and what the compiler detects as mandatory to perform before applying the change.