Usare la funzionalità di migrazione sul posto per eseguire la migrazione di ambiente del servizio app v1 e v2 a ambiente del servizio app v3
Nota
La funzionalità di migrazione descritta in questo articolo viene usata per la migrazione automatizzata (stessa subnet) sul posto di ambiente del servizio app v1 e v2 a ambiente del servizio app v3. Per informazioni sulla funzionalità di migrazione side-by-side, vedere Eseguire la migrazione a ambiente del servizio app v3 usando la funzionalità di migrazione side-by-side. Per informazioni sulle opzioni di migrazione manuale, vedere Opzioni di migrazione manuale. Per informazioni sulla scelta dell'opzione di migrazione più adatta, vedere Albero delle decisioni del percorso di migrazione. Per altre informazioni su ambiente del servizio app v3, vedere panoramica di ambiente del servizio app v3.
È possibile eseguire automaticamente la migrazione ambiente del servizio app v1 e v2 a ambiente del servizio app v3 usando la funzionalità di migrazione sul posto. Per altre informazioni sul processo di migrazione e per verificare se il ambiente del servizio app supporta la migrazione in questo momento, vedere la panoramica della funzionalità di migrazione sul posto.
Importante
È consigliabile usare questa funzionalità per gli ambienti di sviluppo prima di eseguire la migrazione di ambienti di produzione per evitare problemi imprevisti. Fornire commenti e suggerimenti relativi a questo articolo o alla funzionalità usando i pulsanti nella parte inferiore della pagina.
Prerequisiti
Assicurarsi di comprendere come la migrazione a ambiente del servizio app v3 influisce sulle applicazioni. Esaminare il processo di migrazione per comprendere la sequenza temporale del processo e dove e quando è necessario partecipare. Esaminare anche le domande frequenti, che possono rispondere ad alcune domande.
Assicurarsi che non siano presenti blocchi nella rete virtuale, nel gruppo di risorse, nella risorsa o nella sottoscrizione. Blocca le operazioni della piattaforma durante la migrazione.
Assicurarsi che non siano presenti criteri di Azure che bloccano le azioni necessarie per la migrazione, incluse le modifiche alla subnet e le creazioni delle risorse del servizio app Azure. I criteri che bloccano le modifiche e le creazioni delle risorse possono causare il blocco o l'esito negativo della migrazione.
Poiché il ridimensionamento è bloccato durante la migrazione, è necessario ridimensionare l'ambiente in base alle dimensioni desiderate prima di avviare la migrazione. Se è necessario ridimensionare l'ambiente dopo la migrazione, è possibile farlo al termine della migrazione.
È consigliabile usare il portale di Azure per l'esperienza di migrazione sul posto. Se si decide di usare l'interfaccia della riga di comando di Azure per la migrazione, seguire la procedura descritta qui in ordine e come scritto, perché si effettuano chiamate api REST di Azure. È consigliabile usare l'interfaccia della riga di comando di Azure per effettuare queste chiamate API. Per informazioni su altri metodi, vedere Informazioni di riferimento sull'API REST di Azure.
Per questa guida, installare l'interfaccia della riga di comando di Azure o usare Azure Cloud Shell e usare una shell Bash.
Nota
È consigliabile usare una shell Bash per eseguire i comandi indicati in questa guida. I comandi potrebbero non essere compatibili con le convenzioni di PowerShell e i caratteri di escape.
1. Ottenere l'ID ambiente del servizio app
Eseguire i comandi seguenti per ottenere l'ID ambiente del servizio app e archiviarlo come variabile di ambiente. Sostituire i segnaposto per il nome e i gruppi di risorse con i valori per il ambiente del servizio app di cui si vuole eseguire la migrazione. ASE_RGe VNET_RG sono uguali se la rete virtuale e ambiente del servizio app si trovano nello stesso gruppo di risorse.
ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)
2. Verificare che la migrazione sia supportata
Il comando seguente controlla se il ambiente del servizio app è supportato per la migrazione. Se viene visualizzato un errore o se il ambiente del servizio app si trova in uno stato non integro o sospeso, non è possibile eseguire la migrazione in questo momento. Vedere la sezione relativa alla risoluzione dei problemi per le descrizioni dei potenziali messaggi di errore che è possibile ottenere. Se l'ambiente non è supportato per la migrazione tramite la funzionalità di migrazione sul posto o si vuole eseguire la migrazione a ambiente del servizio app v3 senza usare la funzionalità di migrazione sul posto, vedere le opzioni di migrazione manuale. Questo comando convalida anche che il ambiente del servizio app sia nella versione di compilazione supportata per la migrazione. Se il ambiente del servizio app non si trova nella versione di build supportata, è necessario avviare l'aggiornamento manualmente. Per altre informazioni sull'aggiornamento della premigration, vedere Verificare che la migrazione sia supportata usando la funzionalità di migrazione sul posto per l'ambiente del servizio app.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"
Se non sono presenti errori, la migrazione è supportata ed è possibile continuare con il passaggio successivo.
Se è necessario avviare un aggiornamento per aggiornare il ambiente del servizio app alla versione di compilazione supportata, eseguire il comando seguente. Eseguire questo comando solo se si verifica un errore nel passaggio di convalida e viene richiesto di aggiornare il ambiente del servizio app.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"
3. Generare indirizzi IP per la nuova risorsa ambiente del servizio app v3
Eseguire il comando seguente per creare nuovi indirizzi IP. Il completamento di questo passaggio richiede circa 15 minuti. Non ridimensionare o apportare modifiche al ambiente del servizio app esistente durante questo periodo.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"
Eseguire il comando seguente per controllare lo stato di questo passaggio:
az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status
Se il passaggio è in corso, si ottiene lo stato .Migrating Dopo aver visualizzato lo stato Ready, eseguire il comando seguente per visualizzare i nuovi indirizzi IP. Se i nuovi indirizzi IP non vengono visualizzati immediatamente, attendere alcuni minuti e riprovare.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"
Nota
A causa di un bug noto, per le migrazioni ambiente del servizio app ELB, l'indirizzo IP in ingresso può cambiare di nuovo una volta completato il passaggio di migrazione. Prepararsi a aggiornare nuovamente le risorse dipendenti con il nuovo indirizzo IP in ingresso al termine del passaggio di migrazione. Questo bug viene risolto e verrà risolto il prima possibile. Aprire un caso di supporto in caso di domande o dubbi su questo problema o richiedere assistenza per il processo di migrazione.
4. Aggiornare le risorse dipendenti con nuovi indirizzi IP
Usando i nuovi indirizzi IP, aggiornare le risorse o i componenti di rete per assicurarsi che il nuovo ambiente funzioni come previsto dopo il completamento della migrazione. È responsabilità dell'utente eseguire eventuali aggiornamenti necessari.
Questo passaggio è anche un buon momento per esaminare le modifiche alle dipendenze di rete in ingresso e in uscita quando si passa a ambiente del servizio app v3. Queste modifiche includono la modifica della porta per Azure Load Balancer, che ora usa la porta 80. Non eseguire la migrazione fino a quando non si completa questo passaggio.
5. Delegare la subnet ambiente del servizio app
ambiente del servizio app v3 richiede che la subnet in cui si trova abbia una singola delega di Microsoft.Web/hostingEnvironments. Le versioni precedenti non richiedono questa delega. È necessario verificare che la subnet sia delegata correttamente e aggiornare la delega (se necessario) prima della migrazione. È possibile aggiornare la delega eseguendo il comando seguente o passando alla subnet nel portale di Azure.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
6. Verificare che non ci siano blocchi nella rete virtuale
I blocchi della rete virtuale bloccano le operazioni della piattaforma durante la migrazione. Se la rete virtuale ha blocchi, è necessario rimuoverli prima della migrazione. Se necessario, è possibile aggiungere nuovamente i blocchi al termine della migrazione.
I blocchi possono esistere in tre ambiti: sottoscrizione, gruppo di risorse e risorsa. Quando si applica un blocco in un ambito padre, tutte le risorse in tale ambito ereditano lo stesso blocco. Se sono stati applicati blocchi nella sottoscrizione, nel gruppo di risorse o nell'ambito delle risorse, è necessario rimuoverli prima della migrazione. Per altre informazioni sui blocchi e sull'ereditarietà dei blocchi, vedere Bloccare le risorse per proteggere l'infrastruttura.
Usare il comando seguente per verificare se la rete virtuale ha blocchi:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Eliminare eventuali blocchi esistenti usando il comando seguente:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Per i comandi correlati per verificare se la sottoscrizione o il gruppo di risorse ha blocchi, vedere le informazioni di riferimento sull'interfaccia della riga di comando di Azure per i blocchi.
7. Preparare le configurazioni
È possibile rendere ridondante la nuova zona di risorse ambiente del servizio app v3 se l'ambiente esistente si trova in un'area che supporta la ridondanza della zona. È possibile configurare la ridondanza della zona impostando la zoneRedundant proprietà su true.
La ridondanza della zona è una configurazione facoltativa. È possibile impostarlo solo durante la creazione della nuova risorsa ambiente del servizio app v3. Non è possibile rimuoverlo in un secondo momento. Per altre informazioni, vedere Scegliere le configurazioni ambiente del servizio app v3. Se non si vuole configurare la ridondanza della zona, non includere il zoneRedundant parametro .
Se il ambiente del servizio app esistente usa un suffisso di dominio personalizzato, è necessario configurarne uno per la nuova risorsa ambiente del servizio app v3 durante il processo di migrazione. La migrazione non riesce se non si configura un suffisso di dominio personalizzato e ne viene attualmente usata una. La migrazione non riesce anche se si tenta di aggiungere un suffisso di dominio personalizzato durante la migrazione a un ambiente non configurato. Per altre informazioni sui suffissi di dominio personalizzati ambiente del servizio app v3, inclusi i requisiti, le istruzioni dettagliate e le procedure consigliate, vedere Suffisso di dominio personalizzato per le ambiente del servizio app.
Nota
Se si configura un suffisso di dominio personalizzato, quando si aggiungono le autorizzazioni di rete nell'insieme di credenziali delle chiavi di Azure, assicurarsi che l'insieme di credenziali delle chiavi consenta l'accesso dai nuovi indirizzi IP in uscita del ambiente del servizio app generati nel passaggio 3.
Se la migrazione non include un suffisso di dominio personalizzato e non si abilita la ridondanza della zona, è possibile passare alla migrazione.
Per impostare queste configurazioni, creare un file denominato parameters.json con i dettagli seguenti in base allo scenario in uso. Non includere le proprietà per un suffisso di dominio personalizzato se questa funzionalità non si applica alla migrazione. Prestare attenzione al valore della proprietà, perché questa configurazione è irreversibile dopo la zoneRedundant migrazione. Impostare il valore della kind proprietà in base alla versione di ambiente del servizio app esistente. I valori accettati per la kind proprietà sono ASEV1 e ASEV2.
Se si esegue la migrazione senza un suffisso di dominio personalizzato e si abilita la ridondanza della zona, usare questo codice:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true
}
}
Se si usa un'identità gestita assegnata dall'utente per la configurazione del suffisso di dominio personalizzato e si sta abilitando la ridondanza della zona, usare questo codice:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true,
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Se si usa un'identità gestita assegnata dal sistema per la configurazione del suffisso di dominio personalizzato e non si abilita la ridondanza della zona, usare questo codice:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
8. Eseguire la migrazione a ambiente del servizio app v3 e controllare lo stato
Dopo aver completato tutti i passaggi precedenti, è possibile avviare la migrazione. Assicurarsi di comprendere le implicazioni della migrazione.
Questo passaggio richiede da tre a sei ore per le migrazioni da v2 a v3 e fino a sei ore per le migrazioni da v1 a v3, a seconda delle dimensioni dell'ambiente. Durante questo periodo di tempo, il tempo di inattività dell'applicazione è di circa un'ora. Il ridimensionamento, le distribuzioni e le modifiche alle ambiente del servizio app esistenti vengono bloccate durante questo passaggio.
Includere il parametro nel comando seguente se si abilita la body ridondanza della zona e/o si configura un suffisso di dominio personalizzato. Se nessuna di queste configurazioni si applica alla migrazione, è possibile rimuovere il parametro dal comando .
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json
Eseguire i comandi seguenti per controllare lo stato dettagliato della migrazione. Per informazioni sugli stati, vedere le descrizioni dello stato della migrazione.
Il primo comando ottiene l'ID operazione per la migrazione. Copiare il valore della ID proprietà.
az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"
Sostituire il segnaposto per l'ID operazione nel comando seguente con il valore copiato. Questo comando restituisce lo stato dettagliato della migrazione. È possibile eseguire questo comando con la frequenza necessaria per ottenere lo stato più recente.
az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"
Dopo aver ottenuto lo stato Ready, la migrazione viene completata e si dispone di una risorsa ambiente del servizio app v3. Le app sono ora in esecuzione nel nuovo ambiente.
Per ottenere i dettagli del nuovo ambiente, eseguire il comando seguente o passare alla portale di Azure.
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Nota
A causa di un bug noto, per le migrazioni ambiente del servizio app ELB, l'indirizzo IP in ingresso può cambiare al termine del passaggio di migrazione. Controllare gli indirizzi IP di ambiente del servizio app v3 e apportare eventuali aggiornamenti necessari se sono state apportate modifiche dopo il passaggio di generazione ip. Aprire un caso di supporto per eventuali domande o dubbi su questo problema o richiedere assistenza per la conferma dei nuovi indirizzi IP.
1. Verificare che la migrazione sia supportata
Nella portale di Azure passare alla pagina Migrazione per il ambiente del servizio app di cui si sta eseguendo la migrazione. È possibile accedere alla pagina Migrazione selezionando il banner nella parte superiore della pagina Panoramica per il ambiente del servizio app oppure selezionando la voce Migrazione nel menu a sinistra.
Nella pagina Migrazione la piattaforma verifica se la migrazione è supportata per il ambiente del servizio app. Selezionare Convalida e quindi confermare che si vuole procedere con la convalida. Il processo di convalida richiede alcuni secondi.
Se l'ambiente non è supportato per la migrazione, viene visualizzato un banner nella parte superiore della pagina e include un messaggio di errore con un motivo. Per le descrizioni dei messaggi di errore che possono essere visualizzati se non si è idonei per la migrazione, vedere Risoluzione dei problemi.
Se il ambiente del servizio app non è supportato per la migrazione in questo momento o l'ambiente è in uno stato non integro o sospeso, non è possibile usare la funzionalità di migrazione. Se l'ambiente non è supportato per la migrazione con la funzionalità di migrazione sul posto o si vuole eseguire la migrazione a ambiente del servizio app v3 senza usare la funzionalità di migrazione sul posto, vedere le opzioni di migrazione manuale.
Se è necessario avviare un aggiornamento per aggiornare il ambiente del servizio app alla versione di build supportata, viene richiesto di avviare l'aggiornamento. Selezionare Aggiorna per avviare l'aggiornamento. Al termine dell'aggiornamento, si supera la convalida e si può usare la funzionalità di migrazione per avviare la migrazione.
Se la migrazione è supportata per il ambiente del servizio app, procedere con il passaggio successivo del processo. La pagina Migrazione illustra la serie di passaggi per completare la migrazione.
2. Generare indirizzi IP per la nuova risorsa ambiente del servizio app v3
In Ottieni nuovi indirizzi IP verificare di aver compreso le implicazioni e selezionare il pulsante Start . Il completamento di questo passaggio richiede circa 15 minuti. Non è possibile ridimensionare o apportare modifiche al ambiente del servizio app esistente durante questo periodo.
3. Aggiornare le risorse dipendenti con nuovi indirizzi IP
Al termine del passaggio precedente, vengono visualizzati gli indirizzi IP per la nuova risorsa ambiente del servizio app v3. Usare i nuovi indirizzi IP per aggiornare tutte le risorse e i componenti di rete in modo che il nuovo ambiente funzioni come previsto dopo il completamento della migrazione. È responsabilità dell'utente eseguire eventuali aggiornamenti necessari.
Questo passaggio è anche un buon momento per esaminare le modifiche alle dipendenze di rete in ingresso e in uscita nel passaggio a ambiente del servizio app v3. Queste modifiche includono la modifica della porta per Azure Load Balancer, che ora usa la porta 80. Non passare al passaggio successivo fino a quando non si è verificato l'esecuzione di questi aggiornamenti.
4. Delegare la subnet ambiente del servizio app
ambiente del servizio app v3 richiede che la subnet in cui si trova abbia una singola delega di Microsoft.Web/hostingEnvironments. Le versioni precedenti non richiedono questa delega. È necessario verificare che la subnet sia delegata correttamente e aggiornare la delega (se necessario) prima della migrazione. Il portale visualizza un collegamento alla subnet in modo da poter confermare e aggiornare in base alle esigenze.
5. Confermare le modifiche alle dimensioni dell'istanza
I piani di servizio app vengono convertiti da Isolato al livello Isolated v2 corrispondente. Ad esempio, I2 viene convertito in I2v2. Le app potrebbero essere sottoposto a overprovisioning dopo la migrazione, perché il livello Isolated v2 ha più memoria e CPU per ogni dimensione di istanza corrispondente. È possibile ridimensionare l'ambiente in base alle esigenze al termine della migrazione. Per altre informazioni, vedere i dettagli dei prezzi.
6. Verificare che la rete virtuale non abbia blocchi
I blocchi della rete virtuale bloccano le operazioni della piattaforma durante la migrazione. Se la rete virtuale ha blocchi, è necessario rimuoverli prima della migrazione. Se necessario, è possibile aggiungere nuovamente i blocchi al termine della migrazione.
I blocchi possono esistere in tre ambiti: sottoscrizione, gruppo di risorse e risorsa. Quando si applica un blocco in un ambito padre, tutte le risorse in tale ambito ereditano lo stesso blocco. Se sono stati applicati blocchi nella sottoscrizione, nel gruppo di risorse o nell'ambito delle risorse, è necessario rimuoverli prima della migrazione. Per altre informazioni sui blocchi e sull'ereditarietà dei blocchi, vedere Bloccare le risorse per proteggere l'infrastruttura.
Per informazioni dettagliate su come verificare se la sottoscrizione o il gruppo di risorse ha blocchi, vedere Configurare i blocchi.
7. Scegliere le configurazioni
È possibile rendere ridondante la nuova zona di risorse ambiente del servizio app v3 se l'ambiente esistente si trova in un'area che supporta la ridondanza della zona. La ridondanza della zona è una configurazione facoltativa. È possibile impostarlo solo durante la creazione della nuova risorsa ambiente del servizio app v3. Non è possibile rimuoverlo in un secondo momento. Per altre informazioni, vedere Scegliere le configurazioni ambiente del servizio app v3.
Selezionare la casella di controllo Abilitato se si vuole configurare la ridondanza della zona.
Se l'ambiente si trova in un'area che non supporta la ridondanza della zona, la casella di controllo non è disponibile. Se è necessaria una risorsa con ridondanza della zona ambiente del servizio app v3, usare una delle opzioni di migrazione manuale e creare la risorsa in una delle aree che supportano la ridondanza della zona.
Se il ambiente del servizio app esistente usa un suffisso di dominio personalizzato, è necessario configurarne uno per la nuova risorsa ambiente del servizio app v3. Le opzioni di configurazione per un suffisso di dominio personalizzato vengono visualizzate se questa situazione si applica all'utente. Non è possibile eseguire la migrazione fino a quando non si specificano le informazioni necessarie.
Se si vuole usare un suffisso di dominio personalizzato ma non ne è attualmente configurato uno, è possibile configurarne uno al termine della migrazione. Per altre informazioni sui suffissi di dominio personalizzati ambiente del servizio app v3, inclusi i requisiti, le istruzioni dettagliate e le procedure consigliate, vedere Suffisso di dominio personalizzato per le ambiente del servizio app.
Nota
Se si configura un suffisso di dominio personalizzato, quando si aggiungono le autorizzazioni di rete nell'insieme di credenziali delle chiavi di Azure, assicurarsi che l'insieme di credenziali delle chiavi consenta l'accesso dai nuovi indirizzi IP in uscita del ambiente del servizio app generati nel passaggio 2.
Dopo aver aggiunto i dettagli per il suffisso di dominio personalizzato, è disponibile il pulsante Esegui migrazione .
8. Eseguire la migrazione a ambiente del servizio app v3
Dopo aver completato tutti i passaggi precedenti, è possibile avviare la migrazione. Assicurarsi di comprendere le implicazioni della migrazione, incluso ciò che accade durante questo periodo.
Questo passaggio richiede da tre a sei ore per le migrazioni da v2 a v3 e fino a sei ore per le migrazioni da v1 a v3, a seconda delle dimensioni dell'ambiente. La scalabilità e le modifiche apportate al ambiente del servizio app esistente vengono bloccate durante questo passaggio.
Nota
In rari casi, è possibile che nel portale venga visualizzata una notifica che indica che la migrazione a ambiente del servizio app v3 non è riuscita dopo l'avvio della migrazione. Esiste un bug noto che potrebbe attivare questa notifica anche se la migrazione è in corso. Controllare il log attività per il ambiente del servizio app per determinare la validità di questo messaggio di errore. Nella maggior parte dei casi, l'aggiornamento della pagina risolve il problema e il messaggio di errore scompare. Se il messaggio di errore persiste, contattare il supporto tecnico per assistenza.
A questo punto, gli stati dettagliati della migrazione sono disponibili solo quando si usa l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere la sezione interfaccia della riga di comando di Azure per la migrazione a ambiente del servizio app v3. È possibile controllare lo stato della migrazione con l'interfaccia della riga di comando anche se si usa il portale per eseguire la migrazione.
Al termine della migrazione, è disponibile una risorsa ambiente del servizio app v3 e tutte le app vengono eseguite nel nuovo ambiente. È possibile confermare la versione dell'ambiente controllando la pagina Configurazione per il ambiente del servizio app.
Nota
A causa di un bug noto, per le migrazioni ambiente del servizio app ELB, l'indirizzo IP in ingresso può cambiare al termine del passaggio di migrazione. Controllare gli indirizzi IP di ambiente del servizio app v3 e apportare eventuali aggiornamenti necessari se sono state apportate modifiche dopo il passaggio di generazione ip. Aprire un caso di supporto per eventuali domande o dubbi su questo problema o richiedere assistenza per la conferma dei nuovi indirizzi IP.
Se la migrazione include un suffisso di dominio personalizzato, il dominio viene visualizzato nella sezione Informazioni di base della pagina Panoramica del portale per ambiente del servizio app v1/v2, ma non viene più visualizzato in ambiente del servizio app v3. Per ambiente del servizio app v3, passare invece alla pagina Suffisso di dominio personalizzato per verificare che il suffisso di dominio personalizzato sia configurato correttamente. È anche possibile rimuovere la configurazione se non è più necessaria o configurarla se non ne è stata creata una in precedenza.
Nota
Se la migrazione include un suffisso di dominio personalizzato, la configurazione del suffisso di dominio personalizzato potrebbe risultare danneggiata al termine della migrazione a causa di un bug noto. Il ambiente del servizio app dovrebbe comunque funzionare come previsto. Lo stato danneggiato dovrebbe risolversi entro 6-8 ore. Se la configurazione è danneggiata dopo 8 ore o se il suffisso di dominio personalizzato non funziona, contattare il supporto tecnico.
