Migration vers App Service Environment v3 à l’aide de la fonctionnalité de migration sur place

App Service peut automatiser la migration de votre environnement App Service Environment v1 et v2 vers un environnement App Service Environment v3. Il existe différentes options de migration. Passez en revue l’arbre de décision du chemin de migration pour déterminer quelle option convient le mieux à votre cas d’usage. App Service Environment v3 offre des avantages et des différences de fonctionnalités par rapport aux versions antérieures. Veillez à passer en revue les fonctionnalités prises en charge d’App Service Environment v3 avant de migrer pour réduire le risque d’un problème d’application inattendu.

La fonctionnalité de migration sur place automatise votre migration vers App Service Environment v3 en mettant à niveau votre App Service Environment existant dans le même sous-réseau. Cette option de migration est idéale pour les clients qui souhaitent migrer vers App Service Environment v3 avec des modifications minimales apportées à leurs configurations réseau. Vous devez également être en mesure de supporter environ une heure de temps d’arrêt de l’application. Si vous ne pouvez pas prendre en charge les temps d’arrêt, consultez la fonctionnalité de migration côte à côte ou les options de migration manuelle.

Scénarios pris en charge

Pour le moment, la fonctionnalité de migration sur place ne prend pas en charge les migrations vers App Service Environment v3 dans les régions suivantes :

Microsoft Azure géré par 21Vianet

• Chine orientale 2
• Chine Nord 2

Les configurations App Service Environment suivantes peuvent être migrées à l’aide de la fonctionnalité de migration sur place. Le tableau fournit la configuration App Service Environment v3 lors de l’utilisation de la fonctionnalité de migration sur place selon votre App Service Environment (ASE) existant. Tous les environnements ASE pris en charge peuvent être migrés vers un App Service Environment v3 redondant interzone à l’aide de la fonctionnalité de migration sur place tant que l’environnement se trouve dans une région qui prend en charge la redondance de zone. Vous pouvez configurer la redondance de zone pendant le processus de migration.

Si vous souhaitez que votre nouvel App Service Environment v3 utilise un suffixe de domaine personnalisé et que vous n’en utilisez pas actuellement, le suffixe de domaine personnalisé peut être configuré à tout moment une fois la migration terminée. Pour plus d’informations, consultez Configurer le suffixe de domaine personnalisé pour App Service Environment.

Vous pouvez trouver la version de votre environnement App Service Environment en y accédant dans le portail Azure et en sélectionnant Configuration sous Paramètres sur le côté gauche. Vous pouvez également utiliser Azure Resource Explorer et vérifier la valeur de la propriété kind pour votre environnement App Service Environment.

Limitations de la fonctionnalité de migration sur place

Voici des limitations lors de l’utilisation de la fonctionnalité de migration sur place :

• Votre nouvel App Service Environment v3 se trouve dans le sous-réseau existant utilisé pour votre ancien environnement.
• Vous ne pouvez pas changer la région dans laquelle se trouve votre App Service Environment.
• ELB App Service Environment ne peut pas être migré vers ILB App Service Environment v3 et vice versa.
• Si votre App Service Environment existant utilise un suffixe de domaine personnalisé, vous devez configurer le suffixe de domaine personnalisé pour votre App Service Environment v3 pendant le processus de migration.
  • Si vous ne souhaitez plus utiliser un suffixe de domaine personnalisé, vous pouvez le supprimer une fois la migration terminée.

App Service Environment v3 ne prend pas en charge les fonctionnalités suivantes que vous utilisez peut-être avec votre instance App Service Environment v1 ou v2 actuelle.

• Configuration d’une liaison TLS/SSL basée sur une adresse IP avec vos applications
• App Service Environment v3 ne revient pas à Azure DNS si vos serveurs DNS personnalisés configurés dans le réseau virtuel ne sont pas en mesure de résoudre un nom donné. Si ce comportement est nécessaire, veillez à disposer d’un redirecteur vers un DNS public ou à inclure Azure DNS dans la liste des serveurs DNS personnalisés.

La fonctionnalité de migration sur place ne prend pas en charge les scénarios suivants. Consultez les options de migration manuelle si votre environnement App Service Environment figure dans l’une de ces catégories.

• App Service Environment v1 dans un réseau virtuel classique
• App Service Environment v2 avec ELB et des adresses IP SSL
• App Service Environment v1 avec ELB et des adresses IP SSL
• App Service Environment avec un nom qui ne respecte pas la limite de caractères. Le nom entier (y compris le suffixe de domaine) doit être de 64 caractères maximum. Par exemple : my-ase-name.appserviceenvironment.net pour ILB et my-ase-name.p.azurewebsites.net pour ELB doivent comporter au plus 64 caractères. Si vous ne respectez pas la limite de caractères, vous devez effectuer une migration manuelle. La limite de caractères spécifique au nom d’un App Service Environment est les suivantes :
  • La limite de caractères du nom d’un App Service Environment ILB est de 36 caractères
  • La limite de caractères du nom d’un App Service Environment ELB est de 42 caractères

La plateforme App Service évalue votre App Service Environment pour confirmer la prise en charge de la migration sur place. Si votre scénario ne passe pas toutes les vérifications de validation, vous ne pouvez pas migrer à l’aide de la fonctionnalité de migration sur place pour le moment. Si votre environnement est dans un état non sain ou suspendu, vous ne pouvez pas effectuer la migration tant que vous n’aurez pas effectué les mises à jour nécessaires.

Dépannage

Si votre App Service Environment échoue aux vérifications de validation ou vous essayez d’effectuer une étape de migration dans le mauvais ordre, l’un des messages d’erreur suivants peut s’afficher :

Vue d’ensemble du processus de migration sur place à l’aide de la fonctionnalité de migration

La migration sur place se compose d’une série d’étapes qui doivent être suivies dans l’ordre. Les points clés sont fournis pour un sous-ensemble des étapes. Il est important de comprendre ce qui se passe pendant ces étapes et comment votre environnement et vos applications sont affectés. Après avoir consulté les informations suivantes et lorsque vous êtes prêt à effectuer la migration, suivez le guide pas à pas.

Valider le fait que la migration est prise en charge à l’aide de la fonctionnalité de migration en place pour votre ASE

La plateforme valide que votre ASE peut être migré en utilisant la fonctionnalité de migration en place. Si votre ASE ne passe pas avec succès toutes les vérifications de validation, vous ne pouvez pas migrer en utilisant la fonctionnalité de migration en place pour le moment. Consultez la section Résolution des problèmes pour plus d’informations sur les causes possibles de l’échec de validation. Si votre environnement est dans un état non sain ou suspendu, vous ne pouvez pas effectuer la migration tant que vous n’aurez pas effectué les mises à jour nécessaires. Si vous ne pouvez pas effectuer une migration à l’aide de la fonctionnalité de migration en place, consultez les options de migration manuelle.

La validation vérifie également si votre ASE est sur la build minimale requise pour la migration. Cette build peut être plus récente que la build standard qui est déployée lors du cycle de mise à jour/maintenance de routine de la plateforme. La build minimale est mise à jour régulièrement pour vous assurer que les derniers correctifs et améliorations des bogues sont disponibles. Si votre ASE ne se trouve pas sur la build minimale, vous devez démarrer la mise à niveau vous-même. Cette mise à niveau est un processus standard qui n’affecte pas votre ASE, mais vous ne pouvez pas mettre à l’échelle ou apporter des modifications à votre ASE pendant la mise à niveau. Vous ne pouvez effectuer une migration avant la fin de la mise à niveau. Les mises à niveau peuvent prendre 8 à 12 heures ou plus en fonction de la taille de votre environnement. Si vous planifiez une fenêtre de temps spécifique pour votre migration, vous devez exécuter la vérification de validation 24 à 48 heures avant votre heure de migration planifiée, afin de vous assurer que vous disposez du temps nécessaire pour une mise à niveau s’il est nécessaire d’en réaliser une.

Générer des adresses IP pour votre nouvel environnement App Service Environment v3

La plateforme crée la nouvelle adresse IP entrante (si vous migrez un App Service Environment avec ELB) et les nouvelles adresses IP sortantes. Les activités avec votre App Service Environment existant ne seront pas interrompues pendant que ces adresses IP sont en cours de création. Toutefois, vous ne pouvez pas mettre à l’échelle ni modifier votre environnement existant. Ce processus prend environ 15 minutes.

Une fois l’opération terminée, vous recevez les nouvelles adresses IP utilisées par votre futur App Service Environment v3. Ces nouvelles adresses IP n’ont aucun effet sur votre environnement existant. Les adresses IP utilisées par votre environnement existant continuent d’être utilisées jusqu’à ce que votre environnement existant soit arrêté pendant l’étape de migration.

Mettre à jour les ressources dépendantes avec les nouvelles adresses IP

Vous disposez de la nouvelle adresse sortante par défaut vers les adresses publiques Internet une fois les nouvelles adresses IP créées. Pour préparer la migration, vous pouvez ajuster les pare-feux externes, le routage DNS, les groupes de sécurité réseau et toute autre ressource s’appuyant sur ces adresses IP. Pour l’App Service Environment avec ELB, vous disposez également de la nouvelle adresse IP entrante que vous pouvez utiliser pour configurer de nouveaux points de terminaison avec des services comme Traffic Manager ou Azure Front Door. Il vous incombe de mettre à jour toutes les ressources qui seront affectées par la modification de l’adresse IP associée au nouvel environnement App Service Environment v3. Ne passez pas à l’étape suivante tant que vous n’avez pas effectué toutes les mises à jour requises. Cette étape est également un bon moment pour passer en revue les modifications des dépendances des réseaux entrantes et sortantes lors du passage à App Service Environment v3, notamment le changement de port pour la sonde d'intégrité Azure Load Balancer qui utilise désormais le port 80.

Déléguer votre sous-réseau d’App Service Environment

L’environnement App Service Environment v3 exige que le sous-réseau où il se trouve dispose d’une seule délégation de Microsoft.Web/hostingEnvironments. La migration échoue si le sous-réseau d’App Service Environment n’est pas délégué ou s’il est délégué à une autre ressource.

Prendre connaissance des changements de taille d’instance

Vos plans App Service sont convertis de la catégorie Isolé à la catégorie Isolé v2 correspondante dans le cadre de la migration. Par exemple, I2 est converti en I2v2. Vos applications peuvent être surprovisionnées après la migration, car le niveau Isolated v2 dispose de plus de mémoire et d’UC par taille d’instance correspondante. Vous avez la possibilité de faire évoluer votre environnement selon vos besoins une fois la migration terminée. Pour plus d’informations, consultez les détails de la référence SKU.

Vérifiez qu’il n’y a pas de verrous sur vos ressources

Les verrous de réseau virtuel bloquent les opérations de plateforme pendant la migration. Si votre réseau virtuel a des verrous, vous devez les supprimer avant la migration. Les verrous peuvent être lus si nécessaire une fois la migration terminée. Les verrous peuvent exister dans trois étendues différentes : abonnement, groupe de ressources et ressource. Lorsque vous appliquez un verrou à une étendue parente, toutes les ressources de cette étendue héritent du même verrou. Si vous avez des verrous appliqués à l’étendue de l’abonnement, de la ressource ou du groupe de ressources, ils doivent être supprimés avant la migration. Pour plus d’informations sur les verrous et l’héritage des verrous, consultez Verrouiller vos ressources pour protéger votre infrastructure.

Assurez-vous qu’aucune stratégie Azure ne bloque la migration

Azure Policy peut être utilisé pour refuser la création et la modification de ressources à certains principaux. Si une stratégie bloque la création d’App Service Environments ou la modification des sous-réseaux, vous devez la supprimer avant de migrer. La stratégie peut être lue si nécessaire une fois la migration terminée. Pour plus d’informations sur Azure Policy, consultez Vue d’ensemble d’Azure Policy.

Choisir vos configurations d’App Service Environment v3

Votre environnement ASE v3 peut être déployé à travers des zones de disponibilité dans les régions qui le prennent en charge. Cette architecture est appelée redondance de zone. La redondance de zone ne peut être configurée que pendant la création de l’environnement ASE. Si vous souhaitez que votre nouvel environnement ASE v3 soit redondant interzone, activez la configuration pendant le processus de migration. Tout environnement ASE qui utilise la fonctionnalité de migration sur place pour migrer peut être configuré en tant que redondant interzone tant que vous utilisez une région qui prend en charge la redondance de zone pour App Service Environment v3. Si votre environnement existant est dans une région qui ne prend pas en charge la redondance de zone, l’option de configuration est désactivée et vous ne pouvez pas la configurer. La fonctionnalité de migration sur place ne prend pas en charge le changement de régions. Si vous souhaitez utiliser une autre région, choisissez l’une des options de migration manuelle.

Si votre App Service Environment existant utilise un suffixe de domaine personnalisé, vous êtes invité à en configurer un pour votre nouvel ASE v3. Vous devez fournir le nom de domaine personnalisé, l’identité managée et le certificat. Pour plus d’informations sur le suffixe de domaine personnalisé App Service Environment v3, notamment les exigences, les instructions pas à pas et les bonnes pratiques, consultez Configurer un suffixe de domaine personnalisé pour App Service Environment. Vous devez configurer un suffixe de domaine personnalisé pour votre nouvel environnement même si vous ne souhaitez plus l’utiliser. Une fois la migration terminée, vous pouvez supprimer la configuration du suffixe de domaine personnalisé si nécessaire.

Si votre migration inclut un suffixe de domaine personnalisé pour App Service Environment v3, le domaine personnalisé n’apparaît plus dans la section Essentials de la page Vue d’ensemble du portail, car il concerne App Service Environment v1/v2. Au lieu de cela, pour App Service Environment v3, accédez à la page Suffixe de domaine personnalisé dans laquelle vous pouvez confirmer que votre suffixe de domaine personnalisé est configuré correctement. En outre, sur App Service Environment v2, si vous avez un suffixe de domaine personnalisé, le nom d’hôte par défaut inclut votre suffixe de domaine personnalisé et est sous la forme APP-NAME.internal.contoso.com. Sur App Service Environment v3, le nom d’hôte par défaut utilise toujours le suffixe de domaine par défaut et est sous la forme APP-NAME.ASE-NAME.appserviceenvironment.net. Cette différence est due au fait qu’App Service Environment v3 conserve le suffixe de domaine par défaut quand vous ajoutez un suffixe de domaine personnalisé. Avec App Service Environment v2, il n’existe qu’un seul suffixe de domaine.

Migrer vers App Service Environment v3

Après avoir effectué les étapes précédentes, vous devez poursuivre la migration dès que possible.

La migration nécessite une fenêtre de service de trois à six heures pour les migrations App Service Environment v2 vers v3. Une fenêtre de service allant jusqu’à six heures est requise en fonction de la taille d’environnement pour les migrations de v1 vers v3. La fenêtre du service peut être étendue dans de rares cas où une intervention manuelle de l’équipe de service est nécessaire. Pendant la migration, les configurations de mise à l’échelle et d’environnement sont bloquées et les événements suivants se produisent :

• L’environnement App Service Environment existant est arrêté et remplacé par le nouvel environnement App Service Environment v3.
• Tous les plans App Service figurant dans l’environnement App Service Environment sont convertis de la catégorie Isolé à la catégorie Isolé v2.
• Toutes les applications figurant dans votre environnement App Service Environment sont momentanément indisponibles. Vous devez vous attendre à environ une heure de temps d’arrêt.
  • Si vous ne pouvez pas subir de temps d’arrêt, consultez la fonctionnalité de migration côte à côte ou les alternatives de migration.
• Les adresses publiques utilisées par l’App Service Environment sont remplacées par les adresses IP générées au cours de l’étape de génération d’adresses IP.

Les états suivants sont disponibles pendant le processus de migration :

Comme dans l’étape de génération d’adresses IP, vous ne pouvez pas mettre à l’échelle ni modifier votre App Service Environment, ni y déployer des applications au cours de ce processus. Une fois la migration terminée, les applications qui figuraient dans l’ancien App Service Environment s’exécutent dans le nouvel App Service Environment v3.

Utiliser la fonctionnalité de migration sur place

Prérequis

Assurez-vous de comprendre comment la migration vers un environnement App Service Environment v3 affecte vos applications. Passez en revue le processus de migration pour comprendre la chronologie du processus, ainsi que l’emplacement et le moment où vous devez vous impliquez. Passez également en revue les FAQ qui peuvent répondre à certaines de vos questions.

Vérifiez qu’il n’y a aucun verrou sur votre réseau virtuel, ressource, groupe de ressources ou abonnement. Les verrous bloquent les opérations de plateforme pendant la migration.

Vérifiez qu’aucune stratégie Azure ne bloque les actions qui sont requises pour la migration, notamment les modifications de sous-réseau et les créations de ressources Azure App Service. Les stratégies bloquant des créations et des modifications de ressources peuvent entraîner l’échec ou le blocage d’une migration.

Comme la mise à l’échelle est bloquée pendant la migration, vous devez mettre à l’échelle votre environnement avec la taille souhaitée avant de commencer la migration. Si vous devez mettre à l’échelle votre environnement après la migration, vous pouvez le faire dès la fin de la migration. Si la mise à l’échelle automatique est activée, si un événement de mise à l’échelle se produit avant que la migration commence, votre migration est bloquée jusqu’à ce que l’événement de mise à l'échelle se termine. Vous devez désactiver la mise à l’échelle automatique avant de démarrer la migration pour éviter ce problème.

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)

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"

az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true
    }
}

{
    "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"
        }
    }
}

{
    "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"
        }
    }
}

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json

az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"

az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

Tarification

La migration de votre environnement App Service Environment ne génère pas de frais. Lorsque vous utilisez la fonctionnalité de migration sur place, vous cessez d’être facturé pour votre App Service Environment précédent dès qu’il s’arrête pendant le processus de migration. Vous commencez à être facturé pour votre nouveau App Service Environnement v3 dès qu’il est déployé. Pour plus d’informations sur les tarifs d’App Service Environment v3, consultez les détails de la tarification.

Lorsque vous migrez depuis des versions précédentes vers App Service Environment v3, vous devez envisager des scénarios susceptibles de réduire votre coût mensuel. Envisagez des réservations et des plans d’économies pour réduire davantage vos coûts. Pour plus d’informations sur les opportunités d’économie de coûts, consultez Opportunités d’économie de coûts après la mise à niveau vers App Service Environment v3.

Réduire vos plans App Service

Les références SKU des plans App Service disponibles pour App Service Environment v3 s’exécutent sur le niveau de service v2 (Iv2) isolé. Le nombre de cœurs et la quantité de RAM sont effectivement doublés à chaque niveau correspondant par rapport au niveau de service isolé. Vos plans App Service sont convertis vers le niveau de service correspondant lors de la migration. Par exemple, vos instances I2 sont converties à I2v2. Alors que I2 a deux cœurs et 7 Go de RAM, I2v2 a quatre cœurs et 16 Go de RAM. Si vous vous attendez à conserver les mêmes exigences de capacité, vous êtes surapprovisionné et vous payez pour du calcul et de la mémoire que vous n’utilisez pas. Dans ce cas, vous pouvez réduire votre instance I2v2 vers I1v2 et avoir un nombre de cœurs et une quantité de RAM similaires à ce que vous aviez avant.

Forum aux questions

• Qu’en est-il si la migration de mon environnement App Service Environment n’est pas prise en charge actuellement ?
  Vous ne pouvez pas migrer en utilisant la fonctionnalité de migration sur place pour le moment. Si vous avez un environnement non pris en charge et que vous souhaitez migrer immédiatement, consultez les options de migration manuelle.
• Comment choisir l’option de migration qui me convient le mieux ?
  Passez en revue l’arbre de décision du chemin de migration pour déterminer quelle option convient le mieux à votre cas d’usage.
• Comment savoir si je dois utiliser la fonctionnalité de migration sur place ?
  La fonctionnalité de migration sur place est idéale pour les clients qui souhaitent migrer vers App Service Environment v3 avec des modifications minimales apportées à leurs configurations réseau et peuvent prendre en charge environ une heure de temps d’arrêt de l’application. Si vous ne pouvez pas prendre en charge les temps d’arrêt, consultez la fonctionnalité de migration côte à côte ou les options de migration manuelle. La fonctionnalité de migration sur place crée votre environnement App Service Environment v3 dans le même sous-réseau que votre environnement existant et utilise la même infrastructure réseau. Vous devrez peut-être tenir compte des changements d'adresses IP entrantes et sortantes si vous avez des dépendances sur ces adresses IP spécifiques.
• Vais-je subir des temps d’arrêt pendant la migration ?
  Oui, vous devez vous attendre à environ une heure de temps d’arrêt pendant la fenêtre de service de trois à six heures au cours de l’étape de migration, alors adaptez votre planification en conséquence. Si vous disposez d’un autre App Service Environment vers lequel vous pouvez diriger le trafic pendant la migration à l’aide de la fonctionnalité de migration sur place, vous pouvez éliminer les temps d’arrêt de l’application. Si vous n’avez pas d’autre App Service Environment et que vous ne pouvez pas prendre en charge les temps d’arrêt, consultez la fonctionnalité de migration côte à côte ou les options de migration manuelle.
• Dois-je effectuer certaines opérations sur mes applications après la migration pour pouvoir les exécuter dans le nouvel environnement App Service Environment ?
  Non. Toutes vos applications qui s’exécutent dans l’ancien environnement sont automatiquement migrées vers le nouvel environnement et s’exécutent comme avant. Aucune entrée utilisateur n’est requise.
• Que se passe-t-il si mon environnement App Service Environment a un suffixe de domaine personnalisé ?
  La fonctionnalité de migration sur place prend en charge ce scénario de migration.
• Que se passe-t-il si mon environnement App Service Environment est épinglé à une zone ?
  App Service Environment v2 épinglé à une zone est maintenant un scénario pris en charge pour la migration au moyen de la fonctionnalité de migration. App Service Environment v3 ne prend pas en charge l’épinglage de zone. Quand vous migrez vers App Service Environment v3, vous pouvez choisir de configurer ou non la redondance de zone.
• Que se passe-t-il si mon App Service Environment a des adresses IP SSL ? IP SSL n’est pas pris en charge sur App Service Environment v3. Vous devez supprimer toutes les liaisons IP SSL avant d’effectuer une migration en utilisant la fonctionnalité de migration ou de l’une des options manuelles. Si vous envisagez d’utiliser la fonctionnalité de migration sur place, une fois que vous avez supprimé toutes les liaisons IP SSL, vous allez effectuer cette vérification de validation et pouvoir effectuer la migration automatisée.
• Quelles propriétés de mon environnement App Service Environment vont changer ?
  Vous utilisez App Service Environment v3. Veillez donc à consulter les fonctionnalités et les différences de fonctionnalités par rapport aux versions précédentes. Pour App Service Environment avec ILB, vous conservez la même adresse IP ILB. Pour l’App Service Environment accessible via Internet, l’adresse IP publique et l’adresse IP sortante sont modifiées. Notez que pour l’environnement App Service Environment avec ELB, il existait auparavant une adresse IP unique pour le trafic entrant et le trafic sortant. Pour App Service Environment v3, ils sont séparés. Pour plus d’informations, consultez Mise en réseau d’App Service Environment v3. Pour une comparaison exhaustive des versions d’App Service Environment, consultez l’article Comparaison de versions d’App Service Environment.
• Que se passe-t-il si la migration échoue ou qu’un problème inattendu survient pendant la migration ?
  Des équipes de support sont disponibles en cas de problème inattendu. Vous devez migrer les environnements de développement avant de toucher les environnements de production pour en savoir plus sur le processus de migration et voir comment il affecte vos charges de travail.
• Qu’advient-il de mon ancien environnement App Service Environment ?
  Si vous décidez de migrer un environnement App Service Environment à l’aide de la fonctionnalité de migration sur place, l’ancien environnement est arrêté, supprimé, tandis que toutes vos applications sont migrées vers un nouvel environnement. Votre ancien environnement n’est plus accessible. Une restauration vers l’ancien environnement n’est pas possible.
• Que se passe-t-il pour mes ressources App Service Environment v1/v2 après le 31 août 2024 ?
  Après le 31 août 2024, si vous n’avez pas migré vers App Service Environment v3, votre App Service Environment v1/v2 et les applications qui y sont déployées ne seront plus disponibles. App Service Environment v1/v2 est hébergé sur des unités d’échelle App Service s’exécutant sur une architecture Cloud Services (classic) qui sera supprimée le 31 août 2024. Pour cette raison, App Service Environment v1/v2 ne sera plus disponible après cette date. Effectuez une migration vers App Service Environment v3 pour que vos applications restent en cours d’exécution ou pour enregistrer ou sauvegarder des ressources ou des données que vous devez conserver.

Étapes suivantes