StackToIT Migration Intelligence Workspace

Applications

Which application each unit belongs to, and each application's migration strategy. Membership is the customer's file only: a unit is confirmed when the selectors of exactly one application match it, a conflict when several applications claim it (it belongs to none of them), unassigned when no selector matches. A module name never makes an application.

By state: 2 groups PROPOSED by StackToIT (nobody has confirmed them, so none is an application yet): 0 Migration-ready · 0 blocked · 0 redesign · 2 not Migration-ready.

No applications file was given, so no unit is grouped into an application. Pass --applications FILE (stacktoit assess --help names the schema of the file) to state the applications and the selectors that assign units to them.

Proposed grouping: SUGGESTED. Suggested from the workloads of the source, not confirmed by the customer: these groups are a reading of names, tags and references in the Terraform. Nothing is an application until the applications file (--applications) or the review file states it, and where it does the stated applications win and the suggestion is shown as a diff against them.

PROPOSED APPLICATION GROUPS — not confirmed

One group per workload that is switched on: an ECS service, a Lambda function, a Kubernetes deployment, stateful set, daemon set, replication controller, pod, job or cron job, a load balancer with the instances and Auto Scaling groups it routes to, an instance or Auto Scaling group no load balancer fronts, or an EKS cluster when the estate holds no Kubernetes workload (such a group is a platform: its workloads are not visible in Terraform). A group holds its workload and the datastores, security groups, roles, log groups, secrets, keys and similar units that only that workload reaches: what the workload depends on (for an ECS service what its task definition names, for a Lambda function what its environment names, for a load balancer what it routes to), what those depend on in turn, the queues, streams, topics, buckets and EventBridge rules that feed a member (an event source mapping, a subscription, a rule target or the permission that names the rule, a bucket notification), the units a policy of a member names in a statement that is not a Deny, the units a DNS record that the workload names points at (a DNS record or a service-discovery registration that only points at a member is shown and adds no member), the datastore behind a security group whose ingress names a security group the workload itself uses, and the units that exist only for a member and depend on it (volumes, autoscaling targets, the secret of a database, the roles and node security group of a cluster, the Service, Ingress, autoscaler, network policy and disruption budget of a Kubernetes workload). An application tag the source states as a literal (Application, App, ApplicationName, AppName, ApplicationId, Workload, or Service where there is none of those) names the application: workloads that share the value are one group, a tagged unit no workload reaches joins the group of its value, and a unit tagged with another value than the group that reaches it is shared. A tag read from a variable is shown and never decides. A unit that more than one group reaches is shared and belongs to no group, unless exactly one of them carries the unit's tag value. The network, the ECS cluster and the gateways belong to no group, and a module name never makes one. A group is named by its application tag, else by the name of its workload, else by the family of its task definition, else by its address. For Google Cloud: a workload is a Cloud Run service, job or worker pool, a Cloud Function, a Compute Engine instance or managed instance group no load balancer fronts, the forwarding rule of a load balancer with the instances, groups and serverless services behind its backend services (the target proxy and the URL map are followed), or a GKE cluster when the estate holds no Kubernetes workload (a platform). A group holds the Cloud SQL, Memorystore, Spanner, Bigtable, Firestore, AlloyDB and Cloud Storage units, and the service accounts, secrets, keys, topics, queues, repositories, disks and addresses, that only the workload reaches: what its runtime configuration names (the environment and the secret mounts of a Cloud Run service or a Cloud Function), what those depend on in turn, and the resources an IAM role binding or member names together with the service account of a member (the role is not read, so it is a reference and not a stated grant). An application label the source states as a literal (application, app, workload, or service where there is none of those) names the application as a tag does; a label read from a variable is shown and never decides.

These groups are not applications: nobody has confirmed them, no unit is a member of an application because of them, and the state count above names them as groups, never as applications. To adopt a group, copy it (its id and selectors) into review/applications.yaml and set review: confirmed on it; an entry that stays review: proposed or is rejected claims no unit. The same groups, one row per group and per unit, are in migration/applications.csv.

Units several groups reach

These units are members of no suggested group and are in no group's totals: more than one workload reaches each of them.

• google_secret_manager_secret.django_settings (google_secret_manager_secret): migrate, server
• google_sql_database_instance.postgres (google_sql_database_instance): migrate, server
• google_storage_bucket.media (google_storage_bucket): migrate, server

Not in the figures of any application or group: the units that more than one group reaches have 33 manual steps and 2 data moves (google_sql_database_instance.postgres, google_storage_bucket.media); the units that no application and no group holds have 9 manual steps and 0 data moves. These steps are in the plan and in its totals; the figures of an application or group count only the steps that name its own units.

Kubernetes manifests in the source — ties to Terraform

The source holds 2 Kubernetes objects and 0 Helm charts. Tied to a Terraform unit by an exact, literal match: 0. Not tied: 2; they belong to no proposed group, because nothing is guessed. A manifest object ties to a Terraform unit only when both state the same kind, the same name and the same namespace as literals (a kubernetes_* resource), or, for a Helm chart, when a helm_release names the chart by the literal local path of its folder. A name or namespace that is a variable, an expression or absent in the manifest ties nothing, and so does a namespace of the resource that is a variable or an expression; a kubernetes_* resource that states no namespace at all stands in the namespace default, which the hashicorp/kubernetes provider gives it, so only a manifest that states the namespace default ties to it. An object that more than one object or unit answers is not tied. A tie is evidence for the PROPOSED group that holds the unit (on every group that reaches a shared unit, labelled shared; on the tie itself when no group holds the unit) and never adds or removes a member. A Secret or ConfigMap that a manifest names and no manifest declares is resolved in Terraform only by the same literal name and namespace of exactly one kubernetes_secret or kubernetes_config_map. Every object, with its relations, is in migration/kubernetes-manifests.csv.

AWS SDK use in the application code of the source — STATIC_CODE_HINT

A static scan of the application code that sits inside the source you gave (4 code files read; it reads Python, JavaScript, TypeScript, Go, Java, Kotlin and C#): import and client tokens only, nothing executed and nothing downloaded. A hit is a hint, not proof of a runtime dependency: the code may be dead, behind a feature flag or never deployed. It changes no class, confidence, eligibility or step of the plan.

No AWS SDK use was found in the code files that were read.