Condividi tramite

Eseguire la migrazione del gateway applicazione di Azure e web application firewall dalla versione 1 alla versione 2

  • Articolo

È stata annunciata la deprecazione dello SKU V1 del gateway applicazione (Standard e WAF) il 28 aprile 2023. Lo SKU V1 viene ritirato il 28 aprile 2026. Per altre informazioni, vedere Eseguire la migrazione dei gateway applicazione dallo SKU V1 allo SKU V2 entro il 28 aprile 2026.

Il gateway applicazione di Azure e web application firewall (WAF) V2 offrono ora funzionalità aggiuntive, ad esempio scalabilità automatica, disponibilità, ridondanza della zona, prestazioni più elevate, operazioni più veloci e velocità effettiva migliorata rispetto alla versione 1. Inoltre, tutte le nuove funzionalità vengono rilasciate per lo SKU V2. Si consiglia di creare ora un piano di migrazione.

I gateway V1 non vengono aggiornati automaticamente alla versione 2. Usare questa guida alla migrazione per pianificare ed eseguire le migrazioni.

In una migrazione sono presenti due fasi:

  1. Eseguire la migrazione della configurazione
  2. Eseguire la migrazione del traffico client

Questo articolo è utile principalmente per la migrazione della configurazione. La migrazione del traffico client varia a seconda dell'ambiente. Alcuni consigli generali vengono forniti in questo articolo.

Prerequisiti

  • Un account Azure con una sottoscrizione attiva. Creare un account gratuitamente.
  • Un gateway applicazione esistente V1 Standard.
  • Assicurarsi di avere i moduli di PowerShell più recenti oppure di usare Azure Cloud Shell nel portale.
  • Se si esegue PowerShell in locale, è anche necessario eseguire Connect-AzAccount per creare una connessione con Azure.
  • Assicurarsi che non sia presente alcun gateway applicazione con il nome appGW V2 specificato e il nome del gruppo di risorse nell’abbonamento V1. Questa operazione riscrive le risorse esistenti.
  • Se viene specificato un indirizzo IP pubblico, assicurarsi che si tratti di uno stato completato. Se non specificato e AppGWResourceGroupName viene fornito, assicurarsi che la risorsa IP pubblica con nome AppGWV2Name-IP non esista in un gruppo di risorse con il nome AppGWResourceGroupName nella sottoscrizione V1.
  • Per lo SKU V1, sono necessari certificati di autenticazione per configurare le connessioni TLS con i server back-end. Lo SKU V2 richiede il caricamento di certificati radice trusted per lo stesso scopo. Mentre V1 consente l'uso di certificati autofirmati come certificati di autenticazione, V2 impone la generazione e il caricamento di un certificato radice autofirmato se vengono usati certificati autofirmati nel back-end.
  • Assicurarsi che nessun'altra operazione sia pianificata nel gateway V1 o nelle risorse associate durante la migrazione.

Azure Cloud Shell

Azure Cloud Shell è un ambiente di shell interattivo ospitato in Azure e usato tramite il browser. È possibile usare Bash o PowerShell con Cloud Shell per usare i servizi di Azure. È possibile usare i comandi preinstallati di Cloud Shell per eseguire il codice contenuto in questo articolo senza dover installare strumenti nell'ambiente locale.

Per avviare Azure Cloud Shell:

Opzione Esempio/Collegamento
Selezionare Prova nell'angolo superiore destro di un blocco di codice o di comando. Quando si seleziona Prova, il codice o il comando non viene copiato automaticamente in Cloud Shell. Screenshot che mostra un esempio di Prova per Azure Cloud Shell.
Passare a https://shell.azure.com o selezionare il pulsante Avvia Cloud Shell per aprire Cloud Shell nel browser. Pulsante per avviare Azure Cloud Shell.
Selezionare il pulsante Cloud Shell nella barra dei menu nell'angolo in alto a destra del portale di Azure. Screenshot che mostra il pulsante Cloud Shell nel portale di Azure

Per usare Azure Cloud Shell:

  1. Avviare Cloud Shell.

  2. Selezionare il pulsante Copia in un blocco di codice (o in un blocco di comando) per copiare il codice o il comando.

  3. Incollare il codice o il comando nella sessione di Cloud Shell selezionando CTRL+MAIUSC+V in Windows e Linux o selezionando CMD+MAIUSC+V in macOS.

  4. Selezionare Invio per eseguire il codice o il comando.

Nota

È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Importante

Eseguire il Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet ogni volta prima di eseguire lo script di migrazione. Questo è necessario per impostare il contesto di Azure attivo sulla sottoscrizione corretta, perché lo script di migrazione potrebbe riordinare il gruppo di risorse esistente se non esiste nel contesto dell’abbonamento corrente. Questo non è un passaggio obbligatorio per la versione 1.0.11 e successive dello script di migrazione.

Importante

È ora disponibile una nuova versione stabile dello script di migrazione, la versione 1.0.11, che contiene importanti correzioni di bug e aggiornamenti. Usare questa versione per evitare potenziali problemi.

Migrazione della configurazione

In questo documento viene fornito uno script di Azure PowerShell. Esegue le operazioni seguenti per semplificare la configurazione:

  • Crea un nuovo gateway Standard_V2 o WAF_V2 in una subnet di rete virtuale specificata.
  • Copia facilmente la configurazione associata al gateway V1 Standard o WAF nel gateway Standard_V2 o WAF_V2 appena creato.

Download dello script

È possibile scaricare lo script di migrazione dalla PowerShell Gallery. È disponibile una nuova versione stabile (versione 1.0.11) dello script di migrazione, che include aggiornamenti e correzioni di bug principali. Si consiglia di usare questa versione stabile.

Uso dello script

Nota

Eseguire il Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet ogni volta prima di eseguire lo script di migrazione. Questo è necessario per impostare il contesto di Azure attivo sulla sottoscrizione corretta, perché lo script di migrazione potrebbe riordinare il gruppo di risorse esistente se non esiste nel contesto dell’abbonamento corrente. Questo non è un passaggio obbligatorio per la versione 1.0.11 e successive dello script di migrazione.

Sono disponibili due opzioni a seconda della configurazione e delle preferenze dell'ambiente PowerShell locale:

  • Se non sono installati i moduli Az di Azure o non è un problema disinstallare i moduli Az di Azure, l'opzione migliore consiste nell'usare l'opzione Install-Script per eseguire lo script.
  • Se è necessario mantenere i moduli Az di Azure, la scelta migliore consiste nello scaricare lo script ed eseguirlo direttamente.

Per determinare se sono installati i moduli Az di Azure, eseguire Get-InstalledModule -Name az. Se non vengono visualizzati moduli Az installati, è possibile usare il metodo Install-Script.

Per usare questa opzione, non è necessario che nel computer siano installati i moduli Az di Azure. Se sono installati, il comando seguente genererà un errore. È possibile disinstallare i moduli Az di Azure oppure usare l'altra opzione per scaricare manualmente lo script ed eseguirlo.

Eseguire lo script con il comando seguente per ottenere la versione più recente:

Install-Script -Name AzureAppGWMigration -Force

Questo comando installa anche i moduli Az necessari.

Eseguire l'installazione usando direttamente lo script

Se sono installati alcuni moduli Az di Azure e non è possibile disinstallarli (o non si vuole disinstallarli), è possibile scaricare manualmente lo script usando la scheda download manuale nel collegamento di download dello script. Lo script viene scaricato come file nupkg non elaborato. Per installare lo script da questo file nupkg, vedere Download manuale del pacchetto.

La versione 1.0.11 è la nuova versione dello script di migrazione che include importanti correzioni dei bug. Si consiglia di usare questa versione stabile.

Come controllare la versione dello script scaricato

Per controllare la versione dello script scaricato, i passaggi sono i seguenti:

  • Estrarre il contenuto del pacchetto NuGet.
  • Aprire il file .PS1 nella cartella e controllare il .VERSION in alto per confermare la versione dello script scaricato
<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Come eseguire lo script

Per eseguire lo script:

  1. Usare Connect-AzAccount per connettersi ad Azure.

  2. Usare Import-Module Az per importare i moduli Az.

  3. Eseguire il cmdlet Set-AzContext per impostare il contesto di Azure attivo sulla sottoscrizione corretta. Questo è un passaggio importante perché lo script di migrazione potrebbe riordinare il gruppo di risorse esistente se non esiste nel contesto della sottoscrizione corrente.

    Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'

  4. Eseguire Get-Help AzureAppGWMigration.ps1 per esaminare i parametri necessari:

    AzureAppGWMigration.ps1
 -resourceId <V1 application gateway Resource ID>
 -subnetAddressRange <subnet space you want to use>
 -appgwName <string to use to append>
 -AppGWResourceGroupName <resource group name you want to use>
 -sslCertificates <comma-separated SSLCert objects as above>
 -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
 -privateIpAddress <private IP string>
 -publicIpResourceId <public IP name string>
 -validateMigration -enableAutoScale

Nota

Durante la migrazione non tentare altre operazioni sul gateway V1 o sulle risorse associate.

Parametri per lo script:

  • resourceId: [String]: obbligatorio: questo parametro è l'ID risorsa di Azure per il gateway V1 standard o WAF V1 esistente. Per trovare questo valore stringa, passare al portale di Azure, selezionare il gateway applicazione o la risorsa WAF e fare clic sul collegamento Proprietà per il gateway. L'ID risorsa si trova in questa pagina.

    È anche possibile eseguire i comandi di Azure PowerShell seguenti per ottenere l'ID risorsa:

    $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id

  • subnetAddressRange: [String]: obbligatorio: questo parametro è lo spazio indirizzi IP assegnato (o si vuole allocare) per una nuova subnet contenente il nuovo gateway V2. Lo spazio indirizzi deve essere specificato nella notazione CIDR. Ad esempio: 10.0.0.0/24. Non è necessario creare questa subnet in anticipo, ma il CIDR deve far parte dello spazio indirizzi della rete virtuale. Lo script lo crea automaticamente se non esiste, altrimenti, usa quello esistente ( assicurarsi che la subnet sia vuota, contenga solo il gateway V2, se presente, e abbia sufficienti indirizzi IP disponibili).

  • appgwName: [String]: facoltativo. Si tratta di una stringa specificata da usare come nome per il nuovo gateway Standard_V2 o WAF_V2. Se questo parametro non viene specificato, il nome del gateway V1 esistente viene usato con il suffisso _V2 aggiunto.

  • AppGWResourceGroupName: [String]: facoltativo. Nome del gruppo di risorse in cui si desidera creare le risorse del gateway applicazione V2 (il valore predefinito è <V1-app-gw-rgname>)

Nota

Assicurarsi che non sia presente alcun gateway applicazione con il nome appGW V2 specificato e il nome del gruppo di risorse nell’abbonamento V1. Questa operazione riscrive le risorse esistenti.

  • sslCertificates: [PSApplicationGatewaySslCertificate]: facoltativo. Un elenco delimitato da virgole di oggetti PSApplicationGatewaySslCertificate creati per rappresentare i certificati TLS/SSL dal gateway V1 deve essere caricato nel nuovo gateway V2. Per ogni certificato TLS/SSL configurato per il gateway V1 standard o WAF V1, è possibile creare un nuovo oggetto PSApplicationGatewaySslCertificate tramite il comando New-AzApplicationGatewaySslCertificate illustrato di seguito. È necessario il percorso del file di certificato TLS/SSL e della password.

    Questo parametro è facoltativo solo se non sono configurati listener HTTPS per il gateway V1 o WAF. Se è disponibile almeno una configurazione del listener HTTPS, è necessario specificare questo parametro.

    $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
$mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
  -CertificateFile <Cert-File-Path-1> `
  -Password $password
$mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
  -CertificateFile <Cert-File-Path-2> `
  -Password $password

    È possibile usare $mySslCert1, $mySslCert2 (delimitato da virgole) nell'esempio precedente come valori per questo parametro nello script.

  • sslCertificates da Keyvault: facoltativo. È possibile scaricare i certificati archiviati in Azure Key Vault e passarli allo script di migrazione. Per scaricare il certificato come file PFX, eseguire questo comando. Questi comandi accedono a SecretId e quindi salvano il contenuto come file PFX.

     $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
 $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
 $password = ConvertTo-SecureString <password> -AsPlainText -Force

 $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
 $secretByte = [Convert]::FromBase64String($pfxSecret)
 $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
 $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
 $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)

 # Write to a file
 [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)

    Per ogni certificato scaricato dal Keyvault, è possibile creare un nuovo oggetto PSApplicationGatewaySslCertificate tramite il comando New-AzApplicationGatewaySslCertificate mostrato qui. È necessario il percorso del file di certificato TLS/SSL e della password.

    //Convert the downloaded certificate to SSL object
$password = ConvertTo-SecureString  <password> -AsPlainText -Force 
$cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password

  • trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: facoltativo. Elenco delimitato da virgole di oggetti PSApplicationGatewayTrustedRootCertificate creati per rappresentare i certificati radice attendibili per l'autenticazione delle istanze back-end dal gateway v2.

    $certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath

    Per creare un elenco di oggetti PSApplicationGatewayTrustedRootCertificate, vedere New-AzApplicationGatewayTrustedRootCertificate.

  • privateIpAddress: [String]: facoltativo. Indirizzo IP privato specifico da associare al nuovo gateway V2. Deve trovarsi dalla stessa rete virtuale assegnata per il nuovo gateway V2. Se non viene specificato, lo script assegna un indirizzo IP privato per il gateway V2.

  • publicIpResourceId: [String]: facoltativo. ResourceId della risorsa dell'indirizzo IP pubblico esistente (SKU standard) nell’abbonamento da assegnare al nuovo gateway V2. Se viene specificato il nome della risorsa IP pubblico, assicurarsi che esista nello stato riuscito. Se non viene specificato, lo script assegna un nuovo indirizzo IP pubblico nello stesso gruppo di risorse. Il nome è il nome del gateway V2 con -IP aggiunto. Se viene specificato AppGWResourceGroupName e non viene specificato un indirizzo IP pubblico, assicurarsi che la risorsa IP pubblica con nome AppGWV2Name-IP non esista in un gruppo di risorse con il nome AppGWResourceGroupName nella sottoscrizione V1.

  • validateMigration: [switch]: facoltativo. Usare questo parametro per abilitare lo script per eseguire alcune convalide di confronto di configurazione di base dopo la creazione del gateway V2 e la copia della configurazione. Per impostazione predefinita, non viene eseguita alcuna convalida.

  • enableAutoScale: [switch]: facoltativo. Usare questo parametro per abilitare la scalabilità automatica nello script nel nuovo gateway V2 dopo la creazione. Per impostazione predefinita, la scalabilità automatica è disabilitata. È sempre possibile abilitarlo manualmente in un secondo momento nel gateway V2 appena creato.

  1. Eseguire lo script usando i parametri appropriati. Il completamento dell'operazione può richiedere da cinque a sette minuti.

    Esempio

    AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -sslCertificates $mySslCert1,$mySslCert2 `
   -trustedRootCertificates $trustedCert `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

Caveats\Limitations

  • Il nuovo gateway V2 ha nuovi indirizzi IP pubblici e privati. Non è possibile spostare facilmente gli indirizzi IP associati al gateway V1 esistente in V2. Tuttavia, è possibile assegnare un indirizzo IP pubblico (non allocato) esistente o privato al nuovo gateway V2.
  • È necessario fornire uno spazio indirizzi IP per un'altra subnet all'interno della rete virtuale in cui si trova il gateway V1. Lo script non può creare il gateway V2 in una subnet che dispone già di un gateway V1. Se la subnet dispone già di un gateway V2, lo script potrebbe funzionare, purché sia disponibile spazio di indirizzi IP sufficiente.
  • Se si dispone di un gruppo di sicurezza di rete o di route definite dall'utente associate alla subnet del gateway V2, assicurarsi che siano conformi ai requisiti del gruppo di sicurezza di rete e requisiti UDR per una corretta migrazione
  • I criteri degli endpoint servizio di rete virtuale non sono attualmente supportati in una subnet del gateway applicazione.
  • Per eseguire la migrazione di una configurazione TLS/SSL, è necessario specificare tutti i certificati TLS/SSL usati nel gateway V1.
  • Se la modalità FIPS è abilitata per il gateway V1, non viene eseguita la migrazione al nuovo gateway V2. La modalità FIPS non è supportata nella versione 2.
  • Se si dispone di un gateway IP privato solo V1, lo script genera un indirizzo IP privato e pubblico per il nuovo gateway V2. Il gateway privato solo V2 è attualmente in anteprima pubblica. Quando diventa disponibile a livello generale, i clienti possono usare lo script per trasferire il proprio gateway IP privato solo V1 a un gateway IP privato solo V2.
  • L'autenticazione NTLM e Kerberos non è supportata dal gateway applicazione V2. Lo script non è in grado di rilevare se il gateway gestisce questo tipo di traffico e può comportare una modifica che causa un'interruzione dai gateway da V1 a V2 se in esecuzione.
  • Dato che il WAFv2 viene creato in modalità di configurazione WAF precedente, è necessaria la migrazione ai criteri WAF.

Migrazione del traffico

Prima di tutto, verificare che lo script sia stato creato correttamente un nuovo gateway V2 con l’esatta configurazione migrata dal gateway V1. È possibile verificarlo dal portale di Azure.

Inviare anche una piccola quantità di traffico attraverso il gateway V2 come test manuale.

Di seguito sono riportati alcuni scenari in cui il gateway applicazione corrente (Standard) può ricevere traffico client e le raccomandazioni per ognuna:

  • Una zona DNS personalizzata (ad esempio, contoso.com) che indica l'indirizzo IP front-end (usando un record A) associato al gateway V1 o WAF V1 standard.

    È possibile aggiornare il record DNS in modo che indichi l'indirizzo IP front-end o l'etichetta DNS associata al gateway applicazione Standard_V2. A seconda della durata (TTL) configurata nel record DNS, la migrazione del traffico client al nuovo gateway V2 potrebbe richiedere del tempo.

  • Una zona DNS personalizzata (ad esempio, contoso.com) che indica l'etichetta DNS (ad esempio: myappgw.eastus.cloudapp.azure.com usando un record CNAME) associata al gateway V1.

    Sono disponibili due opzioni:

    • Se si usano indirizzi IP pubblici nel gateway applicazione, è possibile eseguire una migrazione controllata e granulare usando un profilo di Gestione traffico per instradare in modo incrementale il traffico (metodo di routing del traffico ponderato) al nuovo gateway V2.

      A tale scopo, è possibile aggiungere le etichette DNS dei gateway applicazione V1 e V2 al profilo di Gestione traffico e CNAMEing del record DNS personalizzato (ad esempio, www.contoso.com) al dominio di Gestione traffico (ad esempio, contoso.trafficmanager.net).

    • In alternativa, è possibile aggiornare il record DNS di dominio personalizzato in modo che indichi l'etichetta DNS del nuovo gateway applicazione V2. A seconda della durata (TTL) configurata nel record DNS, la migrazione del traffico client al nuovo gateway V2 potrebbe richiedere del tempo.

  • I client si connettono all'indirizzo IP front-end del gateway applicazione.

    Aggiornare i client per usare gli indirizzi IP associati al gateway applicazione V2 appena creato. Si consiglia di non usare direttamente gli indirizzi IP. Prendere in considerazione l'uso dell'etichetta del nome DNS (ad esempio, yourgateway.eastus.cloudapp.azure.com) associata al gateway applicazione che è possibile usare CNAME nella propria zona DNS personalizzata, ad esempio contoso.com.

Considerazioni sui prezzi

I modelli di determinazione dei prezzi sono diversi per gli SKU V1 e V2 del gateway applicazione. La versione 2 viene addebitata in base al consumo. Vedere Prezzi del gateway applicazione prima di eseguire la migrazione per informazioni sui prezzi.

Linee guida per l'efficienza dei costi

Lo SKU V2 include una serie di vantaggi, ad esempio un aumento delle prestazioni di 5 volte, una maggiore sicurezza con l'integrazione di Key Vault, aggiornamenti più rapidi delle regole di sicurezza in WAF_V2, regole personalizzate WAF, associazioni di criteri e protezione bot. Offre anche scalabilità elevata, routing del traffico ottimizzato e integrazione senza problemi con i servizi di Azure. Queste funzionalità possono migliorare l'esperienza utente complessiva, evitare rallentamenti durante i periodi di traffico elevato ed evitare violazioni dei dati costose.

Sono disponibili cinque varianti nello SKU V1 in base al livello e alle dimensioni: Standard_Small, Standard_Medium, Standard_Large, WAF_Medium e WAF_Large.

SKU V1 Prezzo fisso/mese V2 Prezzo fisso/mese Elemento consigliato
Standard Medio 102.2 179.8 Lo SKU V2 può gestire un numero maggiore di richieste rispetto a un gateway V1, quindi è consigliabile consolidare più gateway V1 in un singolo gateway V2 per ottimizzare i costi. Assicurarsi che il consolidamento non superi i limiti del gateway applicazione. Si consiglia la consolidazione 3:1.
WAF Medium 183.96 262.8 Uguale per lo Standard Medium
Standard Large 467.2 179.58 Per queste varianti, nella maggior parte dei casi, il passaggio a un gateway V2 può offrire un vantaggio migliore rispetto alla versione 1.
WAF Large 654.08 262.8 Uguale per lo Standard Large

Nota

I calcoli illustrati di seguito sono basati su Stati Uniti dell’est e per un gateway con 2 istanze nella versione 1. Il costo della variabile nella versione 2 si basa su una delle 3 dimensioni con utilizzo più elevato: nuove connessioni (50/sec), connessioni persistenti (2500 connessioni persistenti/min), velocità effettiva (1 CU può gestire 2,22 Mbps).

Gli scenari descritti di seguito sono esempi e sono solo a scopo illustrativo. Per informazioni sui prezzi in base all'area geografica, vedere la pagina dei prezzi.

Per ulteriori dubbi sui prezzi, collaborare con il CSAM o contattare il team di supporto per assistenza.

Domande frequenti

Le domande comuni sulla migrazione sono disponibili qui

Passaggi successivi

Informazioni sul gateway applicazione V2