AZURE → STACKIT · COMPLETE GIDS
De complete migratiegids van Azure naar STACKIT
Begin bij de Terraform-code die u al voor Azure hebt. StackToIT leest die, classificeert elke resource, stelt de STACKIT-Terraform op die het kan opstellen en noemt per eigenaarsrol wat alleen een persoon kan beslissen. Daarna richt u de landing zone in, past u in golven toe, verplaatst u de data en voert u de cutover uit. Deze gids volgt die volgorde en toont een echte run op een gemengde omgeving van 11 resources.
De migratie in acht stappen
Elke stap noemt het bestand van de run dat het antwoord bevat. De bestanden staan in de uitvoermap die het commando assess schrijft.
1. De Terraform-code verzamelen
Verzamel de rootmodules voor AzureRM of AzAPI, met hun variabelenbestanden. Een variabele zonder waarde laat een eenheid zonder concept achter, dus geef de engine dezelfde bestanden die uw pipeline gebruikt. StackToIT leest alleen de code en maakt geen verbinding met een Azure-account.
2. Het assessment uitvoeren
Voer stacktoit assess uit op de map. De console toont de brongetallen, hoeveel eenheden een concept hebben gekregen en hoeveel open verzoeken er zijn. Open eerst index.html.
3. De eerste verzoeken beantwoorden
review/inputs.yaml bevat de getypeerde vragen. Eén blokkeert het concept: de doelregio. Andere, zoals de toegestane CIDR's van elke managed service, zijn variabelen van het concept.
4. Beslissingen beoordelen per eigenaarsrol
review/decisions.yaml bevat één record per eigenaarsrol en eenheid. Een review legt vast dat iemand heeft gekeken; die geeft geen enkele stap vrij zolang het concept niet met de antwoorden opnieuw is gegenereerd.
5. Het doel inrichten
Maak de mappen en het project aan, en een Network Area als netwerken elkaar moeten bereiken. migration/landing-zone-requirements.md noemt wat de organisatie vóór de eerste apply moet leveren.
6. In golven toepassen
migration/technical-sequencing.md ordent eenheden op afhankelijkheid. In de onderstaande run komen eerst de managed services en het netwerk, daarna het subnet, vervolgens de server en als laatste de datadisk, omdat die aan de server wordt gekoppeld.
7. De data verplaatsen
migration/data-movement.md noemt elke stateful eenheid met het mechanisme UNKNOWN totdat een persoon er een kiest. StackToIT verplaatst nooit data.
8. Cutover uitvoeren en de instellingen afsluiten
Schakel de applicaties om en sluit of accepteer daarna elke open kritieke instelling in execution/manual/actions.md. Laat de Azure-kant staan totdat de controles zijn afgerond.
Stap 2: het assessment uitvoeren
Een gemengde demo-omgeving die voor deze gids is opgesteld: een virtueel netwerk met één subnet, een Linux-VM met een datadisk, een Redis-cache, een Service Bus-namespace met een wachtrij en een Cosmos DB-account met de MongoDB-API. De run is gedateerd op 4 november 2026. De samenvattende regels zijn overgenomen uit de console van die run.
stacktoit assess . ./out --offline --no-validateSource 11 resources · 7 units · visibility: Complete
Migration 6 drafted · 1 need no resource (of 7 units the draft considered)
Target STACKIT Terraform generated
Attention 7 units to review · 5 open requests (1 block the draft, marked in inputs-template.yaml)11 resources, 7 eenheden
De wachtrij gaat op in de namespace, de koppeling van de datadisk in de disk en de NIC in de VM; de resource group is geen eenheid. Zes eenheden hebben een concept gekregen en één heeft geen resource nodig, het virtuele netwerk.
Wat de run heeft aangemaakt
OpenTofu-stappen voor 10 resourceblokken en 16 handmatige stappen in 11 werkpakketten voor de 25 kritieke instellingen die het concept niet overneemt.
Compute: een VM en zijn disk
Links: de Linux-VM en de managed datadisk. Rechts: de server- en volumeblokken die de engine heeft geschreven; de reviewcommentaren boven elk blok zijn hier weggelaten.
resource "azurerm_linux_virtual_machine" "batch" {
name = "vm-batch-01"
location = azurerm_resource_group.core.location
resource_group_name = azurerm_resource_group.core.name
size = "Standard_D4s_v5"
admin_username = "azureuser"
network_interface_ids = [azurerm_network_interface.batch.id]
admin_ssh_key {
username = "azureuser"
public_key = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyOnlyForTheDemo demo"
}
os_disk {
caching = "ReadWrite"
storage_account_type = "Premium_LRS"
disk_size_gb = 64
}
source_image_reference {
publisher = "Canonical"
offer = "ubuntu-24_04-lts"
sku = "server"
version = "latest"
}
}
resource "azurerm_managed_disk" "batch_data" {
name = "disk-batch-data"
location = azurerm_resource_group.core.location
resource_group_name = azurerm_resource_group.core.name
storage_account_type = "Premium_LRS"
create_option = "Empty"
disk_size_gb = 256
}resource "stackit_server" "batch" {
project_id = var.project_id
name = "vm-batch-01"
machine_type = var.batch_machine_type
availability_zone = var.availability_zone
boot_volume = {
source_type = "image"
source_id = var.batch_image_id
size = 64
delete_on_termination = true
}
keypair_name = stackit_key_pair.batch.name
network_interfaces = [stackit_network_interface.batch_1.network_interface_id]
}
resource "stackit_volume" "batch_data" {
project_id = var.project_id
name = "disk-batch-data"
availability_zone = var.availability_zone
size = 256
performance_class = var.batch_data_performance_class
}Grootte, image en login zijn variabelen
Het machinetype en de image-ID hebben geen standaardwaarde. De Azure-VM-grootte is niet aan een naam te koppelen; u kiest een STACKIT-machinetype. De beheerder azureuser wordt niet overgenomen: de loginnaam is die van het image.
Diskprestaties zijn een keuze
Het bootvolume behoudt zijn grootte en verliest caching en het type Premium_LRS; het datavolume neemt de grootte 256 over zoals opgegeven, plus een variabele voor de prestatieklasse. Koppel in de guest op volume-ID, niet op LUN, omdat de LUN niet wordt overgenomen.
De volgorde telt
De disk is de laatste eenheid, omdat die aan een server wordt gekoppeld die eerst moet bestaan.
Managed services: cache en messaging
Uit dezelfde run. Eerste paneel: de Redis-cache en de Service Bus-namespace. Daarna de Valkey- en RabbitMQ-instances, één paneel per conceptbestand. De wachtrij en de instellingen van de namespace worden niet gegenereerd.
resource "azurerm_redis_cache" "sessions" {
name = "redis-sessions-gwc"
location = azurerm_resource_group.core.location
resource_group_name = azurerm_resource_group.core.name
capacity = 1
family = "C"
sku_name = "Standard"
minimum_tls_version = "1.2"
}
resource "azurerm_servicebus_namespace" "events" {
name = "sb-events-gwc"
location = azurerm_resource_group.core.location
resource_group_name = azurerm_resource_group.core.name
sku = "Standard"
}resource "stackit_valkey_instance" "sessions" {
project_id = var.project_id
name = "redis-sessions-gwc"
plan_name = var.sessions_plan_name
version = var.sessions_version
parameters = {
sgw_acl = join(",", var.sessions_allowed_cidrs)
}
}resource "stackit_rabbitmq_instance" "messaging" {
project_id = var.project_id
name = "messaging"
plan_name = var.rabbitmq_plan_name
version = var.rabbitmq_version
parameters = {
sgw_acl = join(",", var.rabbitmq_allowed_cidrs)
}
}Toegangslijsten hebben geen veilige standaardwaarde
Het concept stelt de toegangslijst in vanuit variabelen zonder standaardwaarde. Het commentaar zegt dat STACKIT zonder lijst zijn standaard-ACL toepast, die de adressen van elke STACKIT-klant omvat. Noem de client-CIDR's voordat u plant.
Een nieuw clientprotocol
Service Bus spreekt AMQP 1.0. De run noemt een AMQP 0-9-1-client voor RabbitMQ, dus producers en consumers wisselen van bibliotheek en de wachtrij wordt handmatig opnieuw aangemaakt.
U kiest de cachegrootte als Valkey-plan
Familie en capaciteit worden niet overgenomen. U kiest het Valkey-plan en clients krijgen nieuwe inloggegevens; data in de cache wordt meestal opnieuw opgebouwd, niet gemigreerd.
Zo wordt de omgeving gekoppeld
| Azure-resource | STACKIT-doel | Migratieklasse |
|---|---|---|
| Virtuele Linux-machine (met NIC) | Compute Engine-server en netwerkinterface | Herconfiguratie |
| Managed disk (met koppeling) | Block Storage-volume gekoppeld aan de server | Herconfiguratie |
| Virtueel netwerk | Projectnetwerk of Network Area van STACKIT | Herconfiguratie |
| Subnet | STACKIT-netwerk met hetzelfde IPv4-prefix | Herconfiguratie |
| Azure Cache for Redis | Key Value Store-instance (Valkey) en inloggegevens | Herconfiguratie |
| Service Bus-namespace (met wachtrij) | RabbitMQ-instance | Replatforming |
| Cosmos DB-account, MongoDB-API | MongoDB Flex-instance | Replatforming |
Klassen zoals de run ze heeft bepaald: 5 RECONFIGURE en 2 REPLATFORM, allemaal met zekerheidsniveau MEDIUM. Andere services volgen hetzelfde patroon; de gidsen voor Azure SQL, AKS en netwerk tonen hun eigen runs.
Hoe de data verhuist, per service
MongoDB-API
Het wire-protocol is hetzelfde, dus clients stappen over met een nieuwe connection string, TLS-CA en inloggegevens. Data verhuist met mongodump en mongorestore. Globale distributie, instelbare consistentie en schaling op request units worden niet overgenomen.
Cache
Data in de cache wordt meestal opnieuw opgebouwd, niet gemigreerd. Alleen voor state die u niet opnieuw kunt opbouwen, zoals sessies die u moet behouden, is een plan nodig.
Wachtrijen
Laat berichten die nog onderweg zijn leeglopen of speel ze opnieuw af, en maak wachtrijen, exchanges en bindings in RabbitMQ opnieuw aan. De run noemt de namespace als eenheid, maar niet als stateful data.
Disks
Een managed disk wordt een volume van dezelfde grootte. De data verhuist met het serverimage of met een bestands- of blokkopie; de engine registreert het mechanisme als nog niet bepaald.
Beslissingen die uw architecten nemen
Identiteit
Wie zich bij de nieuwe services aanmeldt. De run opent instellingen voor de beheerderslogin van de VM en voor de scope van de resource group van elke eenheid; STACKIT kent geen resource groups, dus vertaal hun grenzen naar projecten en rollen.
Netwerkblootstelling
Of elke managed service publiek is of tot een Network Area beperkt, en welke CIDR's die mogen bereiken.
Dimensionering
Machinetype, Valkey-plan, MongoDB-flavor en opslagklassen. Geen daarvan heeft een standaardwaarde in het concept.
Dataverplaatsing
Mechanisme, venster en toegestane downtime per stateful eenheid. De bron noemt er geen enkele.
Dataresidentie
De locatie van elke resource is een open instelling; bevestig de regio en dat de services daar beschikbaar zijn.
Vragen die migratieleiders stellen
Maakt StackToIT verbinding met mijn Azure-abonnement?
Nee. Het leest Terraform- en OpenTofu-rootmodules die zijn geschreven met de provider azurerm of azapi, op verzoek offline. Het leest geen live account, dus buiten Terraform aangemaakte resources worden niet gezien.
Kan ik de gegenereerde Terraform meteen toepassen?
Nee. Het pakket is een voorstel ter beoordeling door uw architecten. In deze run kan geen van de OpenTofu-stappen worden uitgevoerd zoals ze er staan, omdat waarden zoals project_id en de toegangslijsten ontbreken en instellingen openstaan.
Welke Azure-services hebben een managed STACKIT-doel?
Volgens de samengestelde mapping: AKS naar SKE, PostgreSQL en SQL Server naar hun Flex-services, storage accounts naar Object Storage, Key Vault naar Secrets Manager en KMS, Redis naar Valkey, Service Bus naar RabbitMQ en Cosmos DB naar MongoDB Flex of PostgreSQL Flex. App Service en Functions gaan naar Cloud Foundry of SKE. Azure Firewall wordt per geval beslist.
Waar begin ik in de uitvoermap?
Open index.html en lees daarna engineering/architect-report.md voor de bevindingen per eenheid, review/inputs.yaml en review/decisions.yaml voor de vragen, en execution/README.md voor de volgorde van de stappen.
Bronnen
Uw volgende stap: STACKIT.
Vertel ons over uw omgeving, dan laten wij zien wat StackToIT daarvoor oplevert: doelarchitectuur, Terraform-artefacten en een gestructureerd migratieplan.
Laat uw gegevens achter, onze specialisten nemen contact met u op.
Liever zelf een e-mail sturen? connect@stacktoit.com
Hartelijk dank.
Uw verzoek is bij ons binnengekomen. Onze specialisten nemen contact met u op.