Étape 1 : Création d'une tâche de modernisation de SQL Server Étape 2 : connexion à la base de données SQL Server Étape 3 : connecter le référentiel de code source Étape 4 : Création d'un connecteur de déploiement (facultatif)Étape 5 : Confirmez vos ressources Étape 6 : Découverte et évaluation Étape 7 : Générer et réviser le plan de vagues Étape 8 : Conversion du schéma Étape 9 : Migration des données (facultatif)Étape 10 : Transformation du code de l'application Étape 11 : Examiner les résultats de la transformation Étape 12 : Validation et tests Étape 13 : Déploiement

Workflow de modernisation de SQL Server

Cette section décrit étape par étape le processus complet de modernisation de SQL Server à l'aide de AWS Transform.

Étape 1 : Création d'une tâche de modernisation de SQL Server

Commencez votre parcours de modernisation en créant une nouvelle tâche de transformation dans la console AWS Transform.

Connectez-vous à la console AWS Transform
Choisissez Créer une tâche de modernisation
Sélectionnez la tâche de modernisation de Windows, puis sélectionnez Modernisation de SQL Server
Entrez les détails du poste :
- Nom du poste : nom descriptif de votre projet
- Description : description facultative
- Région cible : AWS région de déploiement
Choisissez Create job (Créer un travail).

Important
N'incluez pas d'informations personnelles identifiables (PII) dans le nom de votre poste.

Étape 2 : connexion à la base de données SQL Server

Connectez AWS Transform à votre base de données SQL Server pour activer l'analyse et la conversion des schémas.

Création d'un connecteur de base de données

Dans votre tâche de modernisation de SQL Server, accédez à Connexion aux ressources
Choisissez Se connecter à la base de données SQL Server
Choisissez Créer un nouveau connecteur
Entrez les informations du connecteur :
- Nom du connecteur C : nom descriptif
- AWS ID de compte : compte sur lequel SQL Server est hébergé
Une fois confirmé, vous recevrez un lien d'approbation. Copiez le lien d'approbation pour obtenir l'approbation de votre compte auprès de votre AWS administrateur. Une fois qu'ils ont été approuvés, vous pouvez passer à l'étape suivante.
Une fois que votre administrateur a approuvé la demande de connecteur, cliquez sur Soumettre pour procéder à la configuration de la connexion au code source.

Étape 3 : connecter le référentiel de code source

AWS Transform a besoin d'accéder au code source de votre application .NET pour analyser et transformer le code qui interagit avec votre base de données SQL Server. AWS Transform prend en charge trois méthodes pour fournir du code source.

Choisissez votre méthode d'authentification

Connecteur PAT (Personal Access Token) (recommandé): Idéal pour les équipes qui ont besoin de domaines d'autorisation personnalisés, d'une assistance auto-hébergée pour les fournisseurs ou d'un accès à des API spécifiques au fournisseur, telles que Secrets. GitHub Vous créez un PAT dans votre fournisseur de code source avec des autorisations personnalisées, vous le stockez et AWS Transform le récupère en AWS Secrets Manager cas de besoin. Vous êtes responsable de la gestion de la rotation et de l'expiration des jetons.
AWS CodeConnections: Idéal pour les équipes qui souhaitent une gestion automatisée des informations d'identification. AWS CodeConnections utilise une intégration de fournisseur géré qui gère l'authentification via un flux d'autorisation OAuth 2.0. AWS gère l'ensemble du cycle de vie des informations d'identification, y compris l'actualisation et la rotation automatiques des jetons. Aucune gestion manuelle des informations d'identification n'est requise.
Amazon S3: Téléchargez votre code source directement dans un compartiment Amazon S3. AWS Transform accède au code depuis le bucket pendant la tâche de transformation.

Fonctionnalité	Connecteur PAT (recommandé)	AWS CodeConnections
Gestion des informations d’identification	Manuel (géré par le client)	Automatique (AWS géré)
Cycle de vie des jetons	Rotation manuelle requise	Actualisation automatique
Flexibilité des autorisations	Des oscilloscopes entièrement personnalisables	Autorisations fixes
Self-hosted soutien aux fournisseurs	Pris en charge	Non disponible
Complexité de configuration	Modéré (création et stockage manuels de jetons)	Faible (autorisation unique)
Stockage de jetons	Du client AWS Secrets Manager	Géré par AWS

Configurer un connecteur PAT (recommandé)

Avec un connecteur PAT, vous créez un jeton d'accès personnel dans votre fournisseur de code source avec des autorisations personnalisées, vous le stockez en AWS Secrets Manager toute sécurité et AWS Transform le récupère en cas de besoin. Vous êtes responsable de la gestion du cycle de vie des jetons, y compris la rotation et l'expiration. AWS Transform crée automatiquement le rôle IAM nécessaire avec les autorisations nécessaires pour accéder à votre secret.

Le connecteur PAT prend en charge les fournisseurs suivants, y compris les DNS/URL versions auto-hébergées et personnalisées :

GitHub et GitHub Enterprise Server
GitLab.com et GitLab Self-Managed
Bitbucket Cloud et centre de données Bitbucket
Azure DevOps et Azure DevOps Server

Créez un jeton d'accès personnel

Créez un PAT dans votre fournisseur de code source. Les autorisations requises varient selon le fournisseur. Choisissez l'onglet correspondant à votre fournisseur.

Important

Copiez le jeton immédiatement après sa création. Vous ne pouvez pas le consulter à nouveau. Définissez l'expiration pour la durée de la tâche de transformation. Ne définissez pas l'expiration pour qu'elle n'expire jamais.

Avertissement

Ne validez jamais les jetons PAT dans des référentiels de code et ne les partagez jamais via des canaux non sécurisés. Rangez-les toujours dedans AWS Secrets Manager.

GitHub

Accédez à Paramètres, Paramètres du développeur, Jetons d'accès personnels, Fine-grained Jetons. Sélectionnez les référentiels à transformer et accordez les autorisations suivantes.

Autorisations du référentiel

Autorisation	Accès	Objectif
Table des matières	Lisez et écrivez	Lit le code source et réécrit le code transformé dans le référentiel
Métadonnées	Read-only	Permet d'accéder aux informations de base du référentiel

Autorisations de l'organisation (requises pour les référentiels de l'organisation)

Autorisation	Accès	Objectif
Members	Read-only	Répertorie les organisations auxquelles le jeton a accès pour la découverte du référentiel

GitLab

Accédez à Modifier le profil, puis Accédez aux jetons. Sélectionnez les domaines suivants.

Scope	Objectif
`read_api`	Lit les métadonnées du référentiel, les informations sur le projet, les informations sur les utilisateurs et répertorie les groupes et les branches
`read_repository`	Lit les fichiers de code source et la structure du référentiel à des fins d'analyse
`write_repository`	Réécrit le code transformé dans le référentiel

Bitbucket

Accédez aux paramètres du compte, à la sécurité , à la création et à la gestion des jetons d'API. Les étendues requises dépendent du type de votre jeton.

Workspace/Repository Jeton (ATCT — Authentification du porteur, aucun nom d'utilisateur requis)

Autorisation	Accès	Objectif
Référentiels	Lisez et écrivez	Répertorie les dépôts, lit les branches et écrit le code transformé via git push

Jeton d'API de compte (ATAT — Authentification de base avec e-mail) ou mot de passe d'application (ATBB — Authentification de base avec nom d'utilisateur)

Scope	Objectif
`read:account`	Identifie l'utilisateur authentifié pour résoudre la question de l'appartenance au référentiel
`read:workspace:bitbucket`	Répertorie les espaces de travail auxquels le jeton peut accéder afin que AWS Transform puisse énumérer leurs référentiels. Non obligatoire si vous spécifiez une liste d'espaces de travail dans le secret.
`read:repository:bitbucket`	Répertorie les référentiels et lit les métadonnées et les informations sur les branches
`write:repository:bitbucket`	Réécrit le code transformé dans le référentiel via git push

Azure DevOps

Accédez aux paramètres utilisateur, puis aux jetons d'accès personnels. Sélectionnez Étendue personnalisée. Pour la portée de l'organisation, choisissez Toutes les organisations accessibles (recommandé) ou spécifiez une seule organisation.

Scope	Accès	Objectif
Code	Lire et écrire	Lit le code source, répertorie les référentiels et les branches, et réécrit le code transformé
Profil de l'utilisateur	Lecture	Valide l'accès par jeton et découvre l'identité de l'utilisateur pour la recherche de l'organisation
Gestion des droits des membres	Lecture	Répertorie les organisations auxquelles le jeton a accès pour la découverte du référentiel

Conservez le PAT dans AWS Secrets Manager

Ouvrez la AWS Secrets Manager console.
Choisissez Store a new secret (Stocker un nouveau secret).
Pour Secret type (Type de secret), choisissez Other type of secret (Autre type de secret).
Ajoutez des paires clé-valeur en fonction de votre fournisseur et de votre type d'hébergement :
- Cloud-hosted providers : ajoutez une clé nommée token avec votre PAT comme valeur.
  - Pour Azure DevOps avec une organisation spécifique, ajoutez également une clé organization portant le nom de votre organisation.
  - Pour les mots de passe des applications Bitbucket (ATBB), ajoutez également une clé nommée username avec votre nom d'utilisateur Bitbucket. Pour les jetons d'API de compte Bitbucket (ATAT), ajoutez une clé nommée email avec votre adresse e-mail Bitbucket.
- Self-hosted et DNS/URL fournisseurs personnalisés : ajoutez les clés suivantes : host (URL de votre serveur, par exemplehttps://github.mycompany.com)github, provider_type (gitlab,bitbucket, ouado) et token (votre PAT).
  - Pour Azure DevOps avec une organisation spécifique, ajoutez également une clé organization portant le nom de votre organisation.
  - Pour les mots de passe des applications Bitbucket (ATBB), ajoutez également une clé nommée username avec votre nom d'utilisateur Bitbucket. Pour les jetons d'API de compte Bitbucket (ATAT), ajoutez une clé nommée email avec votre adresse e-mail Bitbucket.
L'exemple suivant montre comment se présente un secret AWS Secrets Manager pour un fournisseur GitHub hébergé dans le cloud :
```
{
  "token": "your-github-personal-access-token"
}
```
L'exemple suivant montre le mot de passe d'une application Bitbucket (ATBB) :
```
{
  "token": "your-bitbucket-app-password",
  "username": "my-bitbucket-username"
}
```
L'exemple suivant montre une GitLab instance auto-hébergée :
```
{
  "host": "https://gitlab.mycompany.com",
  "provider_type": "gitlab",
  "token": "your-gitlab-personal-access-token"
}
```
Choisissez Suivant.
Entrez un nom secret, par exemplegithub-pat-myproject.
(Facultatif) Sélectionnez une clé KMS gérée par le client pour le chiffrement.
Terminez l'assistant et choisissez Store.
Copiez l'ARN secret. Vous avez besoin de cette valeur lorsque vous configurez la tâche AWS Transform.

Si vous utilisez une clé KMS gérée par le client pour chiffrer votre secret (au lieu de la clé AWS gérée par défaut), vous devez mettre à jour la politique de clé KMS pour permettre à AWS Transform de déchiffrer le secret. Ajoutez la déclaration suivante à votre politique de clé KMS gérée par le client :


{
  "Sid": "Allow AWS Transform to decrypt secrets",
  "Effect": "Allow",
  "Principal": {
    "Service": "transform.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.REGION.amazonaws.com",
      "kms:EncryptionContext:SecretARN": "YOUR-SECRET-ARN"
    }
  }
}

Remplacez REGION par votre AWS région (par exempleus-east-1) et YOUR-SECRET-ARN par l'ARN de votre secret. Cette kms:ViaService condition garantit que la clé KMS ne peut être utilisée que via le AWS Secrets Manager service. La kms:EncryptionContext:SecretARN condition limite le déchiffrement à votre secret spécifique.

Pour mettre à jour votre politique relative aux clés KMS :

Ouvrez la console AWS KMS à l'adressehttps://console.aws.amazon.com/kms.
Dans le panneau de navigation, choisissez Clés gérées par le client.
Sélectionnez votre clé KMS.
Dans l'onglet Stratégie de clé choisissez Modifier.
Ajoutez la déclaration de politique à la politique existante.
Sélectionnez Enregistrer les modifications.

Note

Si vous utilisez la clé AWS gérée par défaut (aws/secretsmanager), vous n'avez pas besoin de modifier la politique de clé KMS.

Configurez le AWS Transformer le travail

Dans votre tâche AWS Transform, accédez à Se connecter aux ressources.
Choisissez Connect source code repository.
Sélectionnez PAT Connector comme méthode d'authentification.
Entrez l'ARN secret de l'étape 2.
(Facultatif) Entrez l'ARN de la clé KMS si vous avez utilisé une clé KMS gérée par le client.
Sélectionnez votre référentiel et votre branche.
Sélectionnez Continuer.

AWS Transform crée automatiquement un rôle IAM avec les autorisations requises pour accéder à votre secret.

Rotation et maintenance des jetons

Vous êtes responsable de la rotation des jetons PAT avant leur expiration. Pour faire pivoter un jeton :

Générez un nouveau PAT dans votre fournisseur de code source avec les mêmes autorisations.
Mettez à jour la valeur secrète dans AWS Secrets Manager.
Vérifiez que votre tâche AWS Transform peut accéder au référentiel avec le nouveau jeton.
Révoquez l'ancien PAT dans votre fournisseur de code source.

Résoudre les problèmes liés au connecteur PAT

Accès refusé — PAT non valide: Vérifiez que le PAT n'a pas expiré. Vérifiez que le PAT possède les étendues requises pour votre fournisseur. Vérifiez que le PAT est correctement enregistré AWS Secrets Manager.
Impossible de récupérer le secret: Vérifiez que l'ARN secret est correct. Consultez les journaux des tâches pour vous assurer que AWS Transform a créé le rôle IAM. Si vous utilisez une clé KMS gérée par le client, vérifiez la politique de clé.
Autorisations insuffisantes: Le PAT n'a peut-être pas les étendues requises pour l'opération. Régénérez le PAT avec les étendues requises et mettez à jour la valeur secrète dans. AWS Secrets Manager

Configuration AWS CodeConnections

AWS CodeConnections utilise une intégration de fournisseur géré qui récupère automatiquement les informations d'identification OAuth temporaires via un flux d'autorisation OAuth 2.0. Les autorisations sont configurées dans l'application du fournisseur et gérées entièrement par AWS. Vous autorisez l'application une seule fois et vous gérez l'ensemble AWS de la gestion des informations d'identification.

Dans votre tâche de modernisation de SQL Server, accédez à Connexion aux ressources.
Choisissez Connect source code repository.
Si vous n'avez pas de connexion existante, choisissez Créer une connexion.
Sélectionnez le fournisseur de votre référentiel :
- GitHub / GitHub Entreprise
- GitLab.com
- Bitbucket Cloud
- Référentiels Azure
Suivez le flux d'autorisation de votre fournisseur.
Après autorisation, choisissez Connect.

Sélectionnez votre référentiel et votre branche

Sélectionnez votre référentiel dans la liste.
Choisissez la branche que vous souhaitez transformer (généralement principale, principale ou développer).
(Facultatif) Spécifiez un sous-répertoire si votre application .NET ne se trouve pas à la racine du référentiel.
Sélectionnez Continuer.

Note

AWS Transform crée une nouvelle branche pour le code transformé. Vous pouvez revoir et fusionner les modifications dans le cadre de votre processus normal de révision du code.

Approbation de l'accès au référentiel

Pour GitHub et certaines autres plateformes, l'administrateur du référentiel doit approuver la demande de connexion :

AWS Transform affiche un lien de vérification.
Partagez ce lien avec l'administrateur de votre référentiel.
L'administrateur examine et approuve la demande dans les paramètres de son référentiel.
Une fois que l'administrateur a approuvé la demande, l'état de la connexion passe à Approuvé.

Important

Le processus d'approbation peut prendre du temps en fonction des politiques de votre organisation. Planifiez en conséquence.

Étape 4 : Création d'un connecteur de déploiement (facultatif)

Si vous souhaitez déployer les applications transformées sur votre AWS compte, vous pouvez sélectionner un connecteur de déploiement.

Configurer le connecteur de déploiement

Sélectionnez Oui si vous souhaitez déployer vos applications. Si vous sélectionnez Non, cette étape sera ignorée.
Ajoutez votre AWS compte à l'endroit où vous souhaitez déployer les applications transformées.
Ajoutez un nom qui vous permettra de vous souvenir facilement du connecteur
Soumettez la demande de connecteur pour approbation.

Approbation du connecteur de déploiement

L'administrateur de votre AWS compte doit approuver la demande de connexion pour le connecteur de déploiement.

AWS Transform affiche un lien de vérification
Partagez ce lien avec l'administrateur de votre AWS compte
L'administrateur examine et approuve la demande dans les paramètres de son référentiel
Une fois approuvée, le statut de la connexion passe à Approuvé

Important

Le processus d'approbation peut prendre du temps en fonction des politiques de votre organisation. Planifiez en conséquence.

Étape 5 : Confirmez vos ressources

Une fois connecté à votre base de données et à votre référentiel, AWS Transform vérifie que toutes les ressources requises sont accessibles et prêtes à être transformées.

Quoi AWS Transform vérifie

Connectivité à la base de données : la connexion est active, l'utilisateur dispose des autorisations requises, les bases de données sont accessibles, la version est prise en charge
Accès au référentiel : le référentiel est accessible, une branche existe, des fichiers de projet .NET ont été détectés, des connexions à la base de données peuvent être détectées
Préparation à l'environnement : la configuration VPC prend en charge le DMS, les rôles de AWS service requis existent, la connectivité réseau est établie, la compatibilité régionale est confirmée

Consultez la liste de contrôle avant le vol

Accédez à Confirmer vos ressources dans le plan de travail
Passez en revue les éléments de la liste de contrôle :
- ✅ Connexion à la base de données vérifiée
- ✅ Accès au référentiel confirmé
- ✅ Version .NET prise en charge
- ✅ Entity Framework ou ADO.NET détecté
- ✅ Configuration réseau valide
- ✅ Autorisations requises accordées
Si tous les éléments apparaissent comme complets, choisissez Continuer
Si des éléments comportent des avertissements ou des erreurs, corrigez-les avant de continuer

Étape 6 : Découverte et évaluation

AWS Transform analyse votre base de données SQL Server et votre application .NET pour comprendre l'étendue et la complexité de la modernisation.

Ce qui est découvert

Objets de base de données : tables, vues, index, procédures stockées, fonctions, déclencheurs, contraintes, types de données, colonnes calculées, colonnes d'identité, relations par clé étrangère
Code de l'application : structure du projet .NET, modèles et configurations Entity Framework, code d'accès aux ADO.NET données, chaînes de connexion à la base de données, appels de procédures stockées, requêtes SQL dans le code
Dépendances : quelles applications utilisent quelles bases de données, dépendances entre bases de données, procédures stockées partagées, modèles d'accès aux données communs

Processus de découverte

AWS Transform commence la découverte automatiquement après confirmation de la ressource
La découverte prend généralement 5 à 15 minutes, selon la taille de la base de données et la complexité de l'application
Suivez les progrès dans le journal de travail
AWS Transform affiche des mises à jour en temps réel à mesure que des objets sont découverts

Examiner les résultats des découvertes

Une fois la découverte terminée, accédez à Découverte et évaluation pour passer en revue :

Analyse de base de données :

Nombre d'objets : nombre de tables, de vues, de procédures stockées, de fonctions, de déclencheurs
Score de complexité : évaluation de la complexité de la transformation (faible, moyenne, élevée)
Mesures à prendre : objets pouvant nécessiter l'attention de l'homme
Fonctionnalités prises en charge : fonctionnalités de base de données qui seront converties automatiquement
Fonctionnalités non prises en charge : fonctionnalités nécessitant des solutions de contournement

Analyse des applications :

Type de projet : ASP.NET Core, application console, bibliothèque de classes, etc.
Version .NET : version .NET Core détectée
Cadre d'accès aux données : version Entity Framework ou ADO.NET
Connexions à la base de données : nombre de chaînes de connexion trouvées
Complexité du code : évaluation de la complexité de la transformation

Carte des dépendances :

Représentation visuelle des relations entre l'application et la base de données
Cross-database dépendances
Composants partagés

Comprendre l'évaluation de la complexité

AWS Transform classe votre modernisation en trois catégories :

Complexité	Caractéristiques	Résultat attendu
Faible (classe A)	Modèles SQL standard (ANSI SQL), procédures stockées simples, types de données de base, Entity Framework avec configurations standard	Intervention humaine minimale attendue, taux de réussite élevé en matière d'automatisation
Moyen (classe B)	T-SQL Modèles avancés, procédures stockées complexes avec logique métier, fonctions définies par l'utilisateur, colonnes calculées	Une certaine intervention humaine est requise, un examen par un expert est recommandé
Élevé (classe C)	assemblages CLR, serveurs liés, Service Broker, recherche complexe en texte intégral	Une importante refactorisation humaine est requise, envisagez une approche par étapes

Rapport d’évaluation

AWS Transform génère un rapport d'évaluation détaillé qui inclut :

Résumé avec vue d'ensemble de haut niveau
Inventaire complet des bases de données
Inventaire des applications
Pourcentage de préparation à la transformation
Estimation de l'effort
Stratégies d'évaluation et d'atténuation des risques
Approche recommandée

Vous pouvez télécharger le rapport d'évaluation pour le consulter hors ligne et le partager avec les parties prenantes.

Étape 7 : Générer et réviser le plan de vagues

Pour les grands parcs dotés de multiples bases de données et applications, AWS Transform génère un plan d'onde qui organise la modernisation en groupes logiques.

Qu'est-ce qu'un plan de vagues ?

Un plan ondulatoire organise votre modernisation en phases (vagues) en fonction de :

Dépendances entre les bases de données et les applications
Priorités commerciales
Tolérance au risque
Disponibilité des ressources
Complexité technique

Chaque vague contient un groupe de bases de données et d'applications qui peuvent être modernisées ensemble sans rompre les dépendances.

Passez en revue le plan des vagues

Accédez à la planification des vagues dans le plan de travail
Passez en revue les vagues proposées
Pour chaque vague, passez en revue :
- Bases de données incluses
- Applications incluses
- Dépendances vis-à-vis d'autres vagues
- Durée de transformation estimée
- Niveau de complexité
- Applications déployables

Personnalisez le plan des vagues

Vous pouvez personnaliser le plan Wave en fonction des besoins de votre entreprise de deux manières :

À l'aide de JSON :

Choisissez Télécharger toutes les vagues pour obtenir un fichier JSON contenant toutes les vagues
Modifiez les vagues dans le JSON en :
- Déplacer des bases de données entre les vagues
- Diviser les vagues en petits groupes
- Fusionner des vagues
- Séquence d'ondes changeante
- Ajouter ou supprimer des bases de données du périmètre
Rechargez le fichier JSON sur la console en choisissant Upload wave plan
AWS Transform valide vos modifications et vous avertit en cas de violation des dépendances
Choisissez Confirmer les vagues pour mettre à jour le plan des vagues

À l'aide du chat :

Vous pouvez modifier les plans de vagues en discutant avec l'agent et en lui demandant de déplacer les référentiels et les bases de données vers des vagues spécifiques. Cette approche fonctionne bien si vous devez apporter des modifications mineures aux vagues.

Important

Assurez-vous que les dépendances sont respectées lors de la personnalisation des vagues. La transformation d'une application dépendante avant sa base de données peut entraîner des problèmes.

Modernisation des bases de données

Si vous modernisez une seule base de données et une seule application, AWS Transform crée un plan simple en une seule vague. Vous pouvez passer directement à la transformation sans planification des vagues.

Approuver le plan de vagues

Après avoir révisé et personnalisé (si nécessaire), choisissez Approuver le plan Wave
AWS Transform verrouille le plan de vague et procède à la transformation
Vous pouvez toujours modifier le plan ultérieurement en choisissant Modifier le plan de vagues

Étape 8 : Conversion du schéma

AWS Transform convertit le schéma de votre base de données SQL Server en Aurora PostgreSQL, y compris les tables, les vues, les procédures stockées, les fonctions et les déclencheurs.

Comment fonctionne la conversion de schéma

AWS Transform utilise la conversion de schéma AWS DMS améliorée par l'IA générative pour :

Analyser les schémas et les relations SQL Server
Mapper les types de données de SQL Server aux équivalents PostgreSQL
Transformer T-SQL en PL/pgSQL
Gérez les colonnes d'identité, les colonnes calculées et les contraintes
Valider la conversion et l'intégrité référentielle
Générez des actions pour les objets nécessitant une révision humaine

Conversions prises en charge

Conversion automatique :

Tableaux, vues et index
Clés primaires et clés étrangères
Vérifiez les contraintes et les valeurs par défaut
Types de données les plus courants
Procédures mémorisées simples
Fonctions de base et déclencheurs
Colonnes d'identité (converties en SERIAL ou GENERATED)
Colonnes les plus calculées

Peut nécessiter un examen humain :

Procédures stockées complexes avec des fonctionnalités avancées T-SQL
Server-specific Fonctions SQL (GETUTCDATE, SUSER_SNAME, etc.)
Colonnes calculées avec des expressions complexes
Full-text index de recherche
Opérations sur les types de données XML
Type de données HIERARCHYID (nécessite l'extension LTREE)

Pas automatiquement converti :

Assemblages CLR
Serveurs liés
Courtier de services
Tâches de SQL Server Agent

Démarrer la conversion du schéma

Accédez à la conversion de schéma dans le plan de travail
Vérifiez les paramètres de conversion :
- Version cible de PostgreSQL
- Options d'extension (ltree, PostGIS, etc.)
- Convention d'appellation
Choisissez Commencer la conversion
Suivez les progrès dans le journal de travail
La conversion prend généralement 10 à 30 minutes selon le nombre d'objets de base de données

Passez en revue les résultats de conversion

Une fois la conversion terminée, accédez à Revoir la conversion du schéma :

Résumé de la conversion :

Objets convertis : nombre d'objets convertis avec succès
Mesures à prendre : objets nécessitant une attention humaine
Avertissements : problèmes potentiels à examiner
Erreurs : objets qui n'ont pas pu être convertis

Révision par type d'objet :

Tableaux : mappages de types de données, contraintes, index
Procédures stockées : T-SQL vers la PL/pgSQL conversion
Fonctions : signature des fonctions et modifications de logique
Déclencheurs : modifications de syntaxe et de synchronisation des déclencheurs

Réviser les mesures à prendre

Choisissez Afficher les actions
Pour chaque action, passez en revue :
- Nom de l'objet : objet de base de données
- Type de problème : Ce qui nécessite une attention particulière
- Gravité : critique, avertissement ou information
- Recommandation : résolution suggérée
- Code d'origine : version de SQL Server
- Code converti : version PostgreSQL
Pour chaque action, vous pouvez :
- Accepter : utilisez le code converti
- Modifier : modifiez le code converti
- Drapeau pour plus tard : Marquer pour examen humain après transformation

Exemple : conversion de procédures stockées

Serveur SQL T-SQL :


CREATE PROCEDURE GetProductsByCategory
    @CategoryId INT,
    @PageSize INT = 10
AS
BEGIN
    SET NOCOUNT ON;
    
    SELECT TOP (@PageSize)
        ProductId,
        Name,
        Price,
        DATEDIFF(DAY, CreatedDate, GETUTCDATE()) AS DaysOld
    FROM Products
    WHERE CategoryId = @CategoryId
    ORDER BY Name
END

PostgreSQL PL/pgSQL converti :


CREATE OR REPLACE FUNCTION get_products_by_category(
    p_category_id INTEGER,
    p_page_size INTEGER DEFAULT 10
)
RETURNS TABLE (
    product_id INTEGER,
    name VARCHAR(255),
    price NUMERIC(18,2),
    days_old INTEGER
) AS $$
BEGIN
    RETURN QUERY
    SELECT 
        p.product_id,
        p.name,
        p.price,
        EXTRACT(DAY FROM (NOW() - p.created_date))::INTEGER AS days_old
    FROM products p
    WHERE p.category_id = p_category_id
    ORDER BY p.name
    LIMIT p_page_size;
END;
$$ LANGUAGE plpgsql;

Modifications apportées :

Procédure convertie en fonction renvoyant TABLE
Noms de paramètres préfixés par p_
TOP converti en LIMIT
DATEDIFF converti en EXTRACT
GETUTCDATE () converti en NOW ()
Noms de colonnes convertis en minuscules (convention PostgreSQL)

Approuver la conversion du schéma

Après avoir examiné toutes les mesures à prendre et apporté les modifications nécessaires
Choisissez Approuver la conversion du schéma
AWS Transform prépare le schéma converti pour le déploiement sur Aurora PostgreSQL

Note

Vous pouvez télécharger le schéma converti sous forme de scripts SQL pour une révision hors ligne ou un contrôle de version.

Étape 9 : Migration des données (facultatif)

AWS Transform propose des options pour migrer les données de SQL Server vers Aurora PostgreSQL. La migration des données est facultative et peut être ignorée si vous n'avez besoin que d'une transformation de schéma et de code.

Options de migration des données

Option 1 : Migration des données de production

Migrez vos données de production réelles à l'aide de AWS DMS :

Chargement initial complet de toutes les données
Réplication continue pendant les tests (CDC)
Interruption minimale des temps d'arrêt
Validation des données et contrôles d'intégrité

Option 2 : Ignorer la migration des données

Transformez le schéma et le code uniquement :

Utile pour les development/testing environnements
Quand les données seront migrées séparément
Pour les projets de validation de concept

Configuration de la migration des données

Accédez à Migration des données dans le plan de travail
Choisissez votre option de migration :
- Migrer les données de production
- Ignorer la migration des données
Si vous migrez des données de production, configurez :
- Type de migration : chargement complet ou chargement complet + CDC
- Validation : activer la validation des données
- Performances : taille de l'instance DMS
- Choisissez >Commencer la migration

Processus de migration des données de production

Si vous choisissez de migrer les données de production :

Synchronisation initiale : AWS DMS charge complètement toutes les tables
Réplication continue : (si le CDC est activé) Maintient la synchronisation des données
Validation : vérifie le nombre de lignes et l'intégrité des données
Préparation du découpage : prépare la synchronisation finale

Chronologie de la migration :

Bases de données de petite taille (< 10 Go) : 30 minutes à 2 heures
Bases de données moyennes (10 à 100 Go) : 2 à 8 heures
Bases de données volumineuses (> 100 Go) : plus de 8 heures

Validation des données

AWS Transform valide les données migrées à l'aide des vérifications suivantes :

Comparaison du nombre de lignes (source et cible)
Intégrité de la clé primaire
Relations clés avec l'étranger
Compatibilité des types de données
Résultats des colonnes calculés
Gestion des valeurs nulles

Étape 10 : Transformation du code de l'application

AWS Transform transforme le code de votre application .NET pour qu'il fonctionne avec Aurora PostgreSQL au lieu de SQL Server. Il demande un nom de branche cible dans vos référentiels pour valider le code source transformé. Une fois que vous avez saisi le nom de la branche, AWS Transform crée une nouvelle branche et lance la transformation pour qu'elle corresponde à la base de données PostgreSQL.

Qu'est-ce qui se transforme

Changements apportés à la structure des entités :

Fournisseur de base de données : UseSqlServer () → UseNpgsql ()
Chaînes de connexion : format SQL Server → format PostgreSQL
Mappages de types de données : types SQL Server → types PostgreSQL
DbContext configurations : SQL Server-specific → PostgreSQL-specific
Fichiers de migration : mis à jour pour assurer la compatibilité avec PostgreSQL

ADO.NET Changements :

Classes de connexion : SqlConnection → NpgsqlConnection
Classes de commandes : SqlCommand → NpgsqlCommand
Lecteur de données : SqlDataReader → NpgsqlDataReader
Paramètres : SqlParameter → NpgsqlParameter
Syntaxe SQL S : T-SQL → PostgreSQL SQL

Changements de configuration :

Chaînes de connexion dans appsettings.json
NuGet Packages pour les fournisseurs de bases
Configurations d'injection de dépendances
Startup/Program.cs configurations

Démarrer la transformation du code

Accédez à la section Transformation des applications dans le plan de travail
Vérifiez les paramètres de transformation :
- Version .NET cible (en cas de mise à niveau)
- Version du fournisseur PostgreSQL
- Préférences de style de code
Choisissez Commencer la transformation
Suivez les progrès dans le journal de travail
La transformation prend généralement 15 à 45 minutes selon la taille de la base de code

Étape 11 : Examiner les résultats de la transformation

Avant de procéder au déploiement, examinez les résultats complets de la transformation pour vous assurer que tout est prêt pour les tests.

Vous pouvez télécharger le code transformé depuis la branche du référentiel pour :

Tests et validation locaux
Révision du code dans votre IDE
Intégration à votre CI/CD pipeline
Commit de contrôle de version

Vous pouvez également télécharger le résumé de la transformation pour consulter les modifications en langage naturel apportées par AWS Transform dans le cadre de la transformation.

Résumé de la transformation

Accédez au résumé de la transformation dans le plan de travail
Passez en revue les résultats globaux :
- Conversion de schéma : objets convertis, actions, avertissements
- Migration des données : tables migrées, lignes transférées, état de validation
- Transformation du code : fichiers modifiés, lignes modifiées, problèmes résolus
- Score de préparation : état de préparation global au déploiement

Générer un rapport de transformation

AWS Transform génère un rapport de transformation complet :

Choisissez Générer un rapport
Sélectionnez le type de rapport :
- Résumé : High-level aperçu pour les parties prenantes
- Détails techniques : documentation complète sur la transformation
- Mesures à prendre : Liste des tâches humaines requises
Choisissez Télécharger le rapport

Le rapport inclut :

Portée et objectifs de la transformation
Objets et code transformés
Problèmes rencontrés et solutions
Résultats de la validation
Évaluation de la préparation au déploiement
Recommandations pour les tests

Étape 12 : Validation et tests

Avant le déploiement en production, vérifiez que l'application transformée fonctionne correctement avec Aurora PostgreSQL.

Types de validation

Validation automatique : AWS Transform effectue des contrôles automatisés :

Validation du schéma sur la base de données source
Vérification de l'intégrité des données
Test d'équivalence des requêtes
Validation des chaînes de connexion
Validation de configuration

Validation humaine : vous devez effectuer des tests supplémentaires :

Tests fonctionnels des fonctionnalités de l'application
Tests d'intégration avec d'autres systèmes
Tests de performance et analyses comparatives
Tests d'acceptation par les utilisateurs
Tests de sécurité

Exécuter une validation automatique

Accédez à Validation dans le plan de travail
Choisissez Exécuter la validation
AWS Transform exécute des tests de validation :
- Connectivité à la base
- Compatibilité des schémas
- Intégrité des données
- Création de l'application
- Fonctionnalité de base
Passez en revue les résultats de validation :
- Réussi : tests réussis
- Échec : tests nécessitant une attention particulière
- Avertissements : problèmes potentiels à examiner

Liste de contrôle des tests

Fonctionnalité de base de données :

Toutes les tables sont accessibles
Les procédures stockées s'exécutent correctement
Les fonctions renvoient les résultats attendus
Les déclencheurs se déclenchent correctement
Contraintes appliquées correctement
Les index améliorent les performances des requêtes

Fonctionnalité de l'application :

L'application démarre correctement
Connexions aux bases de données établies
Les opérations CRUD fonctionnent correctement
Les appels de procédures stockées aboutissent
Transactions commit/rollback correctement
La gestion des erreurs fonctionne comme prévu

Intégrité des données :

Le nombre de lignes correspond à la source
Clés primaires uniques
Clés étrangères valides
Colonnes calculées correctes
Gestion des valeurs nulles appropriée
Types de données compatibles

Performances :

Temps de réponse aux requêtes acceptables
Regroupement de connexions configuré
Indices optimisés
Aucun problème de requête N+1
Efficacité des opérations par lots
Utilisation des ressources raisonnable

Étape 13 : Déploiement

Une fois la validation réussie, déployez votre application et votre base de données modernisées en production.

Options de déploiement

Amazon ECS et Amazon EC2 Linux

Pre-deployment liste de contrôle

Avant le déploiement en production :

Tous les tests de validation ont été réussis
Test de performance terminé
Examen de sécurité terminé
Plan de sauvegarde et de restauration documenté
Configuration de la surveillance et des alertes
Équipe formée au nouvel environnement
Les parties prenantes informées du déploiement
Fenêtre de maintenance planifiée

Déploiement sur Amazon ECS

Accédez à Déploiement dans le plan de travail
Choisissez Deploy to ECS
Configurez les paramètres de déploiement :
- Cluster : sélectionnez ou créez un cluster ECS
- Service : Configuration du service ECS
- Définition de tâche : revoir la définition de tâche générée
- Équilibreur de charge : configurer ALB/NLB
- Auto-scaling: définissez des politiques de dimensionnement
Réviser l'infrastructure en tant que code (CloudFormation modèle ou AWS code CDK)
Choisissez Deploy

Surveillez le déploiement

AWS Transform déploie votre application :

Crée un cluster Aurora PostgreSQL
applique le schéma de base de données
Charge les données (le cas échéant)
Déploie des conteneurs d'applications
Configure l'équilibreur de charge
Configure la mise à l'échelle automatique

Surveillez la progression du déploiement et vérifiez :

Provisionnement de l'infrastructure
Initialisation de la base de données
Déploiement de l'application
Contrôles de santé réussis
Application accessible
Les connexions aux bases de données fonctionnent
Journaux indiquant un fonctionnement normal

Post-deployment validation

Après le déploiement :

Test de fumée :

Vérifiez les fonctionnalités critiques
Testez les flux de travail des principaux utilisateurs
Vérifiez les points d'intégration
Surveiller les taux d'erreur

Surveillance des performances :

Suivez les temps de réponse
Surveillance des requêtes de base de données
Vérifier l'utilisation des ressources
Consulter les journaux des applications

Validation par l'utilisateur :

Réaliser des tests d'acceptation par les utilisateurs
Recueillez des commentaires
Résolvez tous les problèmes
Documenter les leçons apprises

Procédures de restauration

Si des problèmes surviennent après le déploiement :

Annulation immédiate :

Revenir à la version précédente de l'application
Revenez à SQL Server (s'il est toujours disponible)
Restaurez à partir d'une sauvegarde si nécessaire

Annulation partielle :

Restaurer des composants spécifiques
Conserver les modifications de la base
Rétablir le code de l'application uniquement

Correctif avancé :

Appliquer le correctif à la version Aurora PostgreSQL
Déployez le code d'application mis à
Moniteur pour la résolution

Important

Gardez votre base de données SQL Server disponible pendant un certain temps après la mise en service afin de permettre la restauration si nécessaire.

Post-deployment optimisation

Après un déploiement réussi :

Réglage des performances :

Optimisez les requêtes lentes
Régler les paramètres du pool de connexions
Fine-tune Paramètres Aurora PostgreSQL
Passez en revue et optimisez les index

Optimisation des coûts :

Right-size Instance Aurora
Configuration appropriée de la mise à l'échelle automatique
Vérifiez les paramètres de stockage
Optimisez la conservation des sauvegardes

Configuration de la surveillance :

Configuration des CloudWatch tableaux de bord
Configurer les alertes
Activer la surveillance améliorée
Configurer les informations sur les performances

Documentation :

Mettre à jour les runbooks
Modifications de l'architecture des documents
Équipe chargée des opérations de formation
Création de guides de résolution des problèmes

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Création d'une tâche de modernisation de SQL Server

Testez et déployez après la transformation