La plupart de services d'assistance privilégient la rapidité. Ce guide, consacré à une migration complète, s'adresse aux équipes qui ne peuvent se permettre de sacrifier l'exhaustivité au profit de la simplicité. Il concerne notamment les opérations de support soumises à des obligations de conformité, la gestion d'un historique de tickets accumulé sur plusieurs années et le besoin concret des agents d'avoir un contexte client complet pour accomplir leur mission.
La migration complète des données d'un service d'assistance ne se fait pas en un clic. Selon les données d' Oracle , plus de 80 % des projets de migration prennent du retard ou dépassent leur budget. De même, les données de l'USC indiquent que 83 % des projets n'atteignent pas leurs objectifs initiaux. Une migration ayant un impact sur les opérations quotidiennes et la conformité à long terme, il est essentiel de la considérer comme un projet stratégique dès le départ.
Ce guide explique en détail comment procéder sans compromettre l'intégrité de vos données, sans perturber votre plateforme cible ni créer de lacune dans votre historique de support qui pourrait vous poser problème six mois plus tard. Pour réussir, suivez ces six étapes : auditez vos données, configurez votre plateforme cible, sélectionnez vos enregistrements, effectuez une démonstration, exécutez la migration complète et validez les résultats.
Que signifie réellement « complet » dans le cadre d'une migration de centre d'assistance ?
Avant toute chose, définissez clairement le périmètre. La migration complète des données est une opération de transfert de données. Il ne s'agit pas d'un service de configuration de plateforme. Une autre idée fausse consiste à croire que la simple vérification du nombre de tickets après le transfert ne prouve pas que la migration a réussi.
Les relations se brisent en silence. Voici les quatre dimensions de complétude à vérifier.
- Exhaustivité des enregistrements. Chaque requête, fil de discussion et entité de type ticket est enregistré, quel que soit son statut : ouvert, en attente, fermé, résolu, fusionné ou spam. Chaque fiche client et organisation, ainsi que chaque membre et structure d’équipe, trouve un équivalent sur la plateforme cible. Tous les articles de la base de connaissances, toutes langues confondues.
- Intégrité des relations. Un ticket lié à un contact lui-même lié à une entreprise doit être transféré vers la plateforme cible avec ces liens intacts, et non sous la forme de trois enregistrements orphelins sans aucun lien entre eux. Helpdesk sont la victime la plus fréquente d'une migration précipitée.
- L'intégralité du contenu garantit que votre nouveau centre d'assistance est identique à l'ancien. L'assistant de migration transfère les pièces jointes et conserve les images intégrées pour que les liens restent toujours actifs. Nous associons les horodatages avec précision pour que les conversations restent chronologiques. Vos agents disposent ainsi du contexte complet dès le premier jour.
- La conformité totale garantit la légalité de vos données. L'outil préserve l'historique des données afin de respecter les délais réglementaires stricts de conservation. En migrant les horodatages et les journaux système d'origine, il préserve l'intégralité de votre piste d'audit. Vous disposez ainsi d'un historique vérifiable pour les contrôles réglementaires.
Si l'une de ces quatre conditions n'est pas remplie, votre migration est incomplète. Une barre de progression à 100 % ne signifie rien si vos données sont corrompues.
Qu’est-ce qu’une migration complète de service d’assistance ne couvre pas ? Les outils de migration de données déplacent vos données, pas vos paramètres.
Vos flux de travail, vos politiques de SLA et votre logique de routage ne seront pas transférés. Vous devrez les recréer manuellement sur votre nouvelle plateforme. Faites-le avant la migration afin que le système fonctionne correctement à l'arrivée de vos données.
Les équipes partent parfois du principe que leur nouveau service d'assistance fonctionnera automatiquement comme l'ancien. Les données sont transférées, mais la logique opérationnelle reste la même.
Si vous avez besoin d'aide pour reconstruire cette logique, faites appel à l'un de nos partenaires d'implémentation. Faye prend en charge Zendesk, Freshdesk, Freshserviceet Salesforce Service Cloud. Envoy couvre ces mêmes plateformes, ainsi que ServiceNow. GrowthDot est spécialisé dans Zendesk, Freshdesk, Intercomet Jira. Aktie Now se concentre sur l'implémentation complète Zendesk en Amérique du Nord, en Amérique latine, en Europe et au Moyen-Orient. Chaque partenaire peut analyser vos besoins de configuration et faire en sorte que votre nouvelle plateforme fonctionne comme l'ancienne.
Phase 1 : Commencez par auditer votre plateforme source
La migration transfère vos données telles quelles. Une migration complète des données d'un service d'assistance, à partir d'une plateforme source désorganisée, aboutit à une plateforme cible complète, mais tout aussi désorganisée. Les équipes qui négligent la phase de découverte et de nettoyage consacrent deux fois plus de temps au dépannage des erreurs après la mise en production. Bien qu'une phase de découverte approfondie représente 5 à 10 % du budget du projet, USC Data démontre qu'elle permet d'éviter plus de 50 % des échecs de migration courants. Cette phase est indispensable pour une complète helpdesk sans perte de données .
Faites l'inventaire de vos types et volumes d'enregistrements
Comptez tous les enregistrements avant de commencer le transfert. Ce nombre établit votre base de validation pour les vérifications finales après la migration.
Documentez ces éléments :
- Billets par statut : ouverts, en attente, fermés
- Contacts et entreprises
- Articles de la base de connaissances par version linguistique
- Les pièces jointes
- types de champs personnalisés
Exportez cet inventaire. Vous le comparerez à votre rapport post-migration lors de la phase 6.
Identifier et corriger les problèmes de qualité des données avant la migration
Avant toute chose, suivez la liste de vérification pré-migration spécifique à votre plateforme source. Les problèmes les plus fréquents après la migration sont : les contacts dupliqués, les relations entre les tickets rompues et les enregistrements orphelins. Nettoyez d’abord, migrez ensuite.
Trois choses à régler avant de lancer quoi que ce soit :
- Fusionnez les contacts en double. Un client, une fiche. Les doublons perturbent la cohérence des relations et créent de la confusion après la migration.
- Harmonisez les étiquettes qui se chevauchent. Regroupez les étiquettes similaires, telles que « problème_de_facturation », « problème_de_facturation » et « facturation », en une seule étiquette. Des étiquettes incohérentes faussent vos rapports sur votre plateforme cible.
- Supprimez les données orphelines. Effacez les automatisations désactivées, les champs personnalisés vides et les réponses prédéfinies inutilisées. Vous n'avez pas besoin de les conserver.
La migration de données révèle des problèmes de qualité. Sans profilage et nettoyage préalables des données sources, des erreurs imprévisibles risquent de survenir. Le temps consacré à cette étape est toujours inférieur à celui nécessaire pour corriger les problèmes après une migration complète du service d'assistance.
Cartographiez vos obligations de conservation en matière de conformité
Définissez vos obligations légales de conservation avant de décider quels documents migrer ou archiver.
| Règlement | Période de rétention minimale | Conformité axée sur la conformité |
|---|---|---|
| HIPAA | 6 ans à compter de la création ou de la dernière utilisation | Informations de santé protégées |
| SOX | 7 ans | Documents financiers et d'audit |
| PCI DSS | 1 an accessible (3 mois immédiats) ; 3 ans au total | environnements de données des titulaires de cartes |
| GDPR Art. 20 | La portabilité des données est garantie, mais pas leur facilité d'utilisation | Accès aux données et droit à l'effacement |
HIPAA Pour une migration de service d'assistance conforme à il est nécessaire d'identifier les tickets concernés par des obligations spécifiques avant de lancer le transfert. Helpdesk conformité GDPR implique la suppression des demandes de suppression et des enregistrements dont la durée de conservation dépasse les limites fixées avant l'importation des données.
Phase 2 : Configuration de pré-migration
Configurer correctement votre plateforme cible garantit la protection de l'intégralité de votre migration de données.
Les données ne peuvent exister isolément. Chaque ticket nécessite un cadre spécifique (un responsable désigné, un statut valide et des champs personnalisés correspondants) pour être chargé correctement. Si ce cadre est absent, l'API rejette les enregistrements.
Pour protéger votre transfert, vous devez effectuer trois étapes de configuration avant d'exécuter votre migration :
Désactiver les automatisations et les déclencheurs sur la plateforme cible
Les services d'assistance actifs utilisent des déclencheurs et des règles temporelles pour automatiser les flux de travail. Si vous les laissez actifs lors d'une importation, le système cible traitera les tickets historiques entrants comme des événements nouveaux.
Le système enverra automatiquement des notifications par e-mail aux clients pour des tickets clôturés il y a des années. Il enfreindra également instantanément les délais de SLA, faussant ainsi vos indicateurs de performance historiques.
Certaines plateformes se désactivent automatiquement pendant l'importation. Imaginez que c'est un interrupteur intégré à votre nouveau système d'assistance. La plateforme détecte une importation de données importante et désactive automatiquement ses notifications jusqu'à la fin de l'importation. Vérifiez que votre plateforme fonctionne de la même manière avant de le supposer.
Vérifiez auprès de l'équipe de migration si votre paire de plateformes prend en charge la suppression des notifications au niveau des requêtes. Si c'est le cas, activez cette fonctionnalité avant l'exécution.
Créez tous les champs personnalisés sur la plateforme cible
Omettre les champs personnalisés de classement est une erreur de configuration très fréquente. Les champs inexistants dans le système cible entraînent une perte de données silencieuse, sans générer d'avertissements d'erreur.
Pour migrer correctement les enregistrements du service d'assistance concernant les champs personnalisés :
- Associer les noms de champs correspondants.
- Créez tous les champs personnalisés dans la cible avant de commencer.
- Utilisez l'assistant de migration pour faire correspondre vos champs sources aux champs cibles.
Vous pouvez créer des champs personnalisés directement via l'assistant de migration. Faites-le avant la migration de démonstration, pas après.
Agents de mise en relation
L'absence d'agents associés entraîne la création de tickets orphelins. Si un agent ne possède pas de compte dans le nouveau système, ses tickets arrivent sans responsable. Pour éviter cela, utilisez des adresses e-mail identiques sur les deux plateformes afin que l'outil de migration les associe automatiquement.
Pour les anciens employés, associez leurs dossiers à une boîte de réception générique ou à un agent actif au lieu de les laisser vides. Vous pouvez également sélectionner un agent par défaut dans les paramètres de l'assistant de migration pour prendre en charge les dossiers non attribués
Phase 3 : Sélection des éléments à migrer
Pour une migration complète des données du service d'assistance, vous devez cocher toutes les cases de l'écran de sélection des objets.
Voici ce que représente chaque objet, pourquoi vous en avez besoin et ce que coûte son abandon.
Tous les billets
Par défaut, l'outil de migration transfère tous les tickets, quel que soit leur statut (ouvert, en attente, fermé, résolu, etc.). Si vous souhaitez limiter le transfert à certains statuts, vous pouvez appliquer des filtres. Cependant, nous vous recommandons vivement de migrer tous les tickets sans exception.
Les tickets clôturés contiennent l'historique de vos échanges avec les clients. Les agents les consultent quotidiennement pour vérifier les interactions, gérer les escalades et fournir des preuves lors des audits de conformité. Exclure un groupe de statut n'entraîne pas de réduction significative du stockage, mais compromet la précision de vos rapports et vos capacités de recherche.
Lorsque vous migrez l'historique de tous les tickets vers votre nouveau helpdesk, n'appliquez pas de filtres de statut sauf si vous avez une raison spécifique et documentée de le faire.
Tous les contacts et entreprises avec leurs relations
Les tickets ne peuvent pas être migrés sans les contacts associés. Chaque ticket doit être lié à une fiche contact sur la plateforme cible ; sans cela, le ticket arrive sans propriétaire ni identité de client.
Les entreprises sont liées aux contacts, et non directement aux tickets. La chaîne de relations est la suivante : entreprise → contact → ticket. Migrer les contacts sans leurs associations d'entreprise perturbe le contexte du compte pour les équipes de support B2B. Les agents perdent la visibilité sur l'organisation à laquelle appartient un contact, ce qui complique considérablement la gestion des comptes et le traitement des escalades.
Migrez vos contacts et entreprises ensemble, en conservant tous les liens. Une liste de contacts sans historique des relations n'est qu'un carnet d'adresses, pas un historique des interactions.
Articles de la base de connaissances dans toutes les versions linguistiques
Lors de la migration de l'ensemble de la base de connaissances multilingue, sélectionnez tous les articles publiés, les brouillons, les catégories et les sous-dossiers en une seule opération. Ne migrez pas vos articles par lots séparés selon la langue. Le déplacement simultané de toutes les versions préserve le lien structurel entre les différentes options linguistiques.
Activez l'option de mise à jour des liens internes entre les articles. Cette fonctionnalité réécrit automatiquement les URL internes afin que chaque référence pointe vers l'emplacement correct sur la plateforme cible.
Les équipes ont souvent tendance à copier-coller manuellement les articles pour gagner du temps. Cette erreur engendre des semaines de travail fastidieux. De plus, elle perturbe les chemins d'accès aux images et les liens internes, ce qui nuit au référencement naturel.
Pièces jointes, images intégrées et commentaires
Pour migrer correctement les pièces jointes et les commentaires helpdesk , vérifiez trois points avant de commencer.
- Vérifiez que votre nouvelle plateforme dispose de suffisamment d'espace pour recevoir tous les fichiers. Si la limite de stockage est atteinte en cours de migration, le transfert s'interrompt et des erreurs système se produisent.
- Migrez les images intégrées en tant que pièces jointes plutôt que de les laisser sous forme de références à la plateforme source. Les images intégrées sont hébergées sur le système source et utilisent des URL basées sur ce système.
- Une fois la plateforme source mise hors service, ces URL cessent de fonctionner et toutes les images intégrées deviennent des icônes cassées. En les migrant en tant que pièces jointes, vous pouvez les héberger sur la plateforme cible afin qu'elles restent accessibles après la migration.
- Vérifiez vos paramètres de confidentialité avant de lancer la migration complète. Cette mesure de sécurité permet de masquer les commentaires internes aux clients lors de la réception des données.
Lors du déplacement de pièces jointes, d'images intégrées et de commentaires, les équipes ont souvent tendance à négliger certains aspects pour gagner de l'espace de stockage ou accélérer le processus. Évitez ces trois erreurs courantes :
- Ne laissez pas les images intégrées sous forme de liens HTML bruts afin d'éviter les icônes d'images cassées lors de la mise hors service de votre ancienne plateforme.
- N’excluez pas les pièces jointes volumineuses ou anciennes afin d’éviter de perdre le contexte essentiel dont vos agents ont besoin pour résoudre les problèmes récurrents.
- N’omettez pas de tester vos paramètres de visibilité des commentaires afin d’éviter d’exposer directement à vos clients les notes internes privées de vos agents.
Les champs personnalisés et leurs valeurs
Chaque type de champ personnalisé nécessite une approche de mappage spécifique.
- Texte et chiffres : correspondance simple et directe.
- Sélection multiple et listes déroulantes : recréez toutes les options sur la plateforme cible avant d’exécuter l’outil.
- Dates : Vérifiez la compatibilité de format entre les deux applications.
- Cases à cocher : Associer les valeurs vrai et faux aux états cibles correspondants.
- Données manquantes : Attribuer des valeurs par défaut aux champs contenant des enregistrements vides.
Configurez les champs cibles avant de lancer le transfert. Si le conteneur n'existe pas, l'assistant de migration ne pourra pas déplacer vos données. Vérifiez également que les deux plateformes utilisent le même format de date. En cas de format incompatible, l'API rejettera l'intégralité de la requête.
Phase 4 : Validation de la migration de démonstration et du mappage des champs
Chaque migration doit d'abord être testée sur un échantillon. La migration de démonstration est une étape de sécurité obligatoire et non une simple formalité. L'outil transfère un petit échantillon représentatif d'environ 20 tickets et articles de la base de connaissances, ainsi que leurs contacts, agents et pièces jointes associés. Ce test permet de valider le comportement des données avant de procéder à un transfert complet.
Comment réaliser une démonstration productive ? Migration
Une fois que l'outil de migration aura terminé l'exécution de l'échantillon, téléchargez le rapport de mappage des données et vérifiez manuellement les enregistrements sur votre nouvelle plateforme.
Utilisez cette liste de contrôle de validation des données de migration helpdesk pour la démonstration :
- Ordre de la conversation : Veillez à respecter l’ordre chronologique exact, sans interruption.
- Valeurs des champs personnalisés : vérifiez que toutes les valeurs correspondent aux attributs corrects.
- Pièces jointes : Ouvrez les fichiers pour vous assurer qu’ils sont accessibles et non endommagés.
- Note interne : Confirmer que les commentaires privés restent invisibles aux clients.
- Contacts : Vérifiez que les tickets renvoient aux profils clients et entreprises appropriés.
N’effectuez pas le transfert final si votre liste de vérification révèle des données corrompues. L’outil propose des essais gratuits et illimités pour vous permettre d’ajuster votre mappage et de refaire des tests jusqu’à l’obtention de données correctes.
Phase 5 : Migration complète des données
Votre équipe continue de travailler sur la plateforme source pendant toute la durée de la migration des données du service d'assistance. Maintenez-la dans l'ancien système jusqu'à la validation post-migration.
Démarrez la migration complète
Avant de cliquer sur le bouton Démarrer, vérifiez que ces cinq affirmations sont vraies. Si l'une d'entre elles est fausse, arrêtez-vous et corrigez-la avant de continuer.
- Des champs personnalisés existent sur la plateforme cible.
- Chaque profil d'agent est associé à un compte cible ou à un utilisateur par défaut désigné.
- Les automatisations, déclencheurs et notifications du système cible sont entièrement désactivés.
- La migration de démonstration a passé tous les contrôles de validation.
- Vous avez téléchargé une sauvegarde complète de vos données depuis votre service d'assistance.
Mise à l'échelle avancée pour les grands ensembles de données
Si vous transférez un volume important d'enregistrements, utilisez ces deux fonctionnalités d'architecture pour gérer les limites de l'API. Veuillez noter qu'elles sont disponibles uniquement avec l'abonnement Signature.
- La migration par intervalles interrompt le transfert de données pendant vos heures de pointe et le reprend la nuit ou le week-end. Cela protège vos opérations en production et évite l'épuisement de votre quota API.
- La migration multithread exécute simultanément plusieurs flux de données en parallèle afin d'optimiser le débit de l'API de la plateforme cible. La vitesse de transfert dépend fortement de votre niveau d'abonnement à la plateforme cible. C'est la solution la plus rapide pour migrer l'intégralité des données de votre centre d'assistance dans des délais stricts.
Delta Migration capture des changements pendant la transition
Une migration delta copie tous les enregistrements nouveaux ou modifiés apparus sur votre plateforme source après le début de la migration complète. Ne transférez pas votre équipe vers le nouveau centre d'assistance avant d'avoir effectué votre migration delta. Un changement de plateforme trop précoce entraînerait la perte de toutes les conversations clients créées pendant la période de migration complète.
Deux choses à savoir :
- Vous devez exécuter votre migration Delta dans les 10 jours suivant la fin du transfert complet des données.
- La migration Delta est disponible uniquement avec le forfait Signature.
Phase 6 : Validation post-migration
Le fait que la barre de progression atteigne 100 % ne signifie pas que votre migration est terminée. La validation confirme que l'historique des tickets et les champs personnalisés ont bien été importés. Veuillez conserver votre système existant actif jusqu'à ce que vous ayez vérifié chaque enregistrement.
Rapprochement du nombre d'enregistrements
Téléchargez votre rapport final de rapprochement des données. Comparez directement vos objectifs chiffrés avec les données de référence établies avant la migration lors de la phase 1 :
- Nombre total de tickets migrés par rapport au nombre de tickets sources
- Nombre total de profils de contacts et d'entreprises migrés par rapport au nombre de sources
- Nombre d'articles de la base de connaissances migrés par version linguistique par rapport au nombre de sources
Examinez et corrigez toute anomalie statistique avant de désactiver votre ancien service d'assistance.
validation des articles de la base de connaissances
Liste de contrôle pour la validation des données de migration du helpdesk concernant le contenu de la base de connaissances :
- Chaque article est disponible dans toutes les options linguistiques.
- La plateforme cible recrée à l'identique votre structure de dossiers et de catégories.
- Tous les liens hypertextes internes fonctionnent correctement après la mise à jour des URL codées en dur vers la nouvelle structure de la plateforme.
- Les images intégrées s'affichent correctement dans le texte.
- Les articles en brouillon restent à l'état de brouillon au lieu d'être publiés automatiquement.
Quand faire appel à des services professionnels
L'assistant de migration automatisé est idéal pour les transferts de données standard. Cependant, les projets de grande envergure ou database nécessitent une intervention manuelle pour éviter toute perte de données et interruption de service.
Voici quatre scénarios où les outils en libre-service présentent des limites, les risques liés à une approche simplifiée et comment y remédier.
Scénario 1 : Vous regroupez plusieurs services d'assistance
La fusion de deux plateformes ou plus suite à une acquisition engendre d'importants chevauchements de données. Il est nécessaire de dédupliquer les profils de contact et de résoudre les conflits entre les champs personnalisés des différents systèmes.
Certains responsables choisissent d'importer databaseséquentiellement, sans plan de mappage principal. Cette méthode écrase les profils utilisateurs actifs et crée des comptes clients en double.
Scénario 2 : Vous avez des dépendances complexes entre vos champs personnalisés
Les types de données non standard, les migrations massives entre plusieurs projets distincts et les champs conditionnels contournent les modèles de mappage standard.
Certaines équipes tentent d'intégrer de force des données relationnelles complexes dans des champs de texte libre standard. Cela entraîne une perte de données silencieuse, car le nouveau système ne peut pas interpréter la structure de données imbriquée.
Scénario 3 : Vous avez besoin d’une piste d’audit réglementaire
Les cadres de conformité stricts exigent des entreprises qu'elles fournissent une chaîne de traçabilité formelle pour toutes les données clients lors d'une modification d'infrastructure.
Certaines équipes tentent de se fier à des journaux d'outils automatisés basiques. Ces derniers réussissent rarement les audits de conformité rigoureux.
Conclusion : La migration des données est un processus en six étapes, et non une simple exportation
La migration complète des données d'un service d'assistance se déroule en six phases pour une raison simple : elle protège vos données dès le premier jour, assure la continuité du service de votre équipe d'assistance et fournit à vos agents des dossiers à jour.
L'ordre est fixe car les premières étapes permettent de cartographier vos champs et de jeter les bases. Les étapes suivantes prennent en charge les tâches les plus complexes. En suivant cette séquence, vous évitez d'intégrer des données dans un système non testé.
Vous souhaitez voir vos champs en action ? Lancez votre migration de démonstration gratuite pour découvrir comment l’assistant de mappage gère vos tickets et articles réels avant de vous engager.
Votre infrastructure est complexe ? Contactez notre équipe pour en savoir plus sur nos services professionnels. Nous vous aiderons à évaluer le volume de votre database et vos besoins en matière de conformité avant le lancement.
Si une migration complète du service d'assistance ne correspond pas à votre calendrier actuel, envisagez d'autres stratégies : consultez le Guide de migration express pour une transition plus rapide, ou consultez le Guide de migration axé sur l'IA pour vous concentrer sur l'automatisation.
Foire aux questions Help Desk Migration
Le délai dépend du volume d'enregistrements et de votre plateforme. Les petits ensembles de données, contenant moins de 50 000 enregistrements, sont généralement traités en un à trois jours. databasevolumineuses, avec 100 000 à 500 000 enregistrements, peuvent nécessiter une à deux semaines. Effectuez une migration de démonstration gratuite pour obtenir une estimation précise du temps nécessaire pour votre ensemble de données.
Non. Chaque service d'assistance utilise sa propre structure d'identifiants interne ; la nouvelle plateforme générera donc de nouveaux identifiants lors de l'importation. L'outil conserve parfaitement vos objets, horodatages et fils de conversation. Vous pouvez télécharger un rapport post-migration pour comparer vos anciens identifiants avec les nouveaux.
Oui, mais vous devez d'abord configurer l'environnement cible. Créez tous vos champs personnalisés dans le nouveau centre d'assistance avant de lancer le transfert. Vérifiez le mappage des champs dans l'assistant de migration et exécutez une démonstration pour vous assurer que vos données sont correctement transférées.
L’article 20 GDPR impose la portabilité des données dans un format structuré, tandis que l’article 17 encadre le traitement des demandes d’effacement. Afin de protéger les droits des consommateurs, utilisez un outil de migration qui préserve la structure de vos données relationnelles. Supprimez les enregistrements dont la durée de conservation dépasse celle prévue par vos règles de conservation avant le transfert. Veillez à signer un accord de traitement des données avec votre prestataire de migration afin de garantir le respect de vos obligations légales.
L'outil de migration déplace les pièces jointes et les images intégrées avec leurs tickets d'origine afin qu'elles restent accessibles. Après le transfert, vérifiez 10 à 20 pièces jointes pour vous assurer qu'elles s'ouvrent correctement. Consultez les limites de taille des fichiers de votre nouvelle plateforme avant de migrer des fichiers particulièrement volumineux.
Oui. Les moteurs d'automatisation utilisent des logiques totalement différentes selon les fournisseurs de logiciels ; il est donc impossible de les transférer automatiquement. Documentez vos règles métier actuelles avant de commencer. La plupart des équipes constatent que jusqu'à 40 % de leurs anciennes règles sont obsolètes, ce qui fait de la migration une excellente occasion d'optimiser vos flux de travail.
