Votre cabinet
Vous cadrez la migration avec votre client, fixez le prix, et décidez de la fenêtre de bascule.
Capacité de migration Migration capacity
Une capacité de migration que vous pouvez chiffrer comme son propre projet.
La marge et la facturation nomment déjà « chiffré séparément » sans jamais le détailler pour un cas précis. Cette page le fait pour la migration : déplacer des charges de travail vers Azure, entre hyperviseurs, ou hors d’un matériel vieillissant — avec sa propre portée, son propre inventaire et son propre prix, distinct de la base mensuelle par usager.
Équipe de livraison
On planifie et exécute le chemin technique de migration — sur site vers Azure, ou déplacement de serveurs entre Hyper-V et VMware — et on retourne ce qui a changé et ce qui reste à valider.
Migration et virtualisation de serveurs
Pour un projet client qui implique de déplacer des serveurs ou des charges de travail — vers Azure, entre hyperviseurs, ou hors d’un matériel vieillissant — plutôt que l’administration quotidienne d’un environnement stable.
Ce qu’il nous faut d’abord
Un accès aux environnements source et cible, un inventaire fermé de ce qui se déplace, et la tolérance de votre client à l’arrêt de service pendant la bascule.
Ce qui est inclus
- Planification de la migration pour l’inventaire confirmé
- Exécution de la bascule convenue, avec un point de retour arrière quand c’est techniquement possible
- Une passe de validation post-migration par rapport à l’inventaire
Traité séparément
- Décider si Azure, un autre nuage, ou la virtualisation sur site est le bon choix — c’est votre conversation-conseil avec le client
- Les termes de licence ou commerciaux d’Azure ou de tout hyperviseur
- L’administration continue après la bascule — elle retourne à la ligne de service régulière
Ce que vous recevez: Une migration complétée et vérifiée par rapport à l’inventaire d’origine, avec les éléments encore ouverts nommés plutôt que présumés réglés.
Ce qu’on vous remet: Un dossier de migration : ce qui a été déplacé, les résultats de validation, et ce qui reste ouvert.
Ce qui rend un chiffrage de migration réel
Un inventaire fermé avant le prix
« Chiffré séparément » ne fonctionne que si la liste de ce qui se déplace arrête de changer en cours de projet.
Une fenêtre d’arrêt réellement acceptée
Nommez le temps d’indisponibilité que votre client a vraiment accepté — pas une hypothèse de votre côté.
Une décision de retour arrière prise avant la bascule
Convenue à l’avance, pas improvisée pendant la bascule elle-même.
Où le projet se termine
Écrivez où la migration finit et où l’administration courante reprend, pour que personne ne suppose une continuité qui n’a pas été convenue.
Ce que ce volet ne comprend pas
- Conseiller quel nuage ou quelle plateforme de virtualisation acheter
- Un échéancier de migration garanti fixé avant que l’inventaire ne soit fermé
- Des tests de compatibilité applicative au-delà de ce qui est convenu à la portée
Questions franches sur la migration
Est-ce que ceci remplace l’administration courante de Microsoft 365 ou des serveurs?+
Non. C’est un travail de projet avec un début et une fin; une fois la validation terminée, l’environnement retourne à l’administration courante décrite sur la page services.
Que se passe-t-il si l’inventaire change en cours de projet?+
C’est une conversation de portée, pas un ajustement silencieux. Un inventaire qui bouge après le prix initial mérite un nouveau prix, pas une expansion tranquille du même chiffrage.