De Salesforce.com à Microsoft Dynamics CRM : comment aborder la migration ?

La connaissance de ces données et de leur structure est importante car elle va vous permettre de définir un plan de migration dans lequel seront déterminés :

• Les éléments qui vont être migrés facilement vs. les éléments qui nécessiteront un travail vs. les éléments qui ne sont pas supportés dans le système cible, et qui devront donc faire l’objet soit d’un travail spécifique soit d’un abandon.

• La méthodologie de migration (comment extraire les données et sous quel format, comment les importer – outil tiers ou méthode native.

Cet article aborde la migration de Salesforce.com vers Microsoft Dynamics CRM sous un angle général, en pointant des éléments sur lesquels la réflexion devrait être approfondie pendant la phase d’audit d’une part et en expliquant comment les résultats de l’audit peuvent être réutilisés dans la configuration de la migration d’autre part.

Le processus, que j’expose, prend pour postulat que vous utiliserez les outils natifs offerts par Microsoft Dynamics CRM et non pas un outil tiers, qui peut avoir son propre processus de traitement de la migration.

–Globalement, un projet de migration devrait implémenter au moins les étapes modélisées dans le graphique cidessous:– ???

Etape 1 : l’audit de l’existant

La première étape consiste en l’étude préalable de l’environnement source, condition sine qua non au bon déroulement de la migration. Il y a, en effet, plus que le simple export de données depuis Salesforce.com / import dans Microsoft Dynamics CRM à prendre en compte. La première chose à aborder est la définition des fonctions de base de Microsoft Dynamics CRM qui devront être configurées (sales, service, marketing…). La plupart des champs standards pourront être directement associés entre les deux outils, les aspects techniques et fonctionnels étant très similaires. Dans Salesforce.com, un email mensuel destiné aux administrateurs peut être utilisé pour analyser ces éléments : la revue de compte personnalisée (personalized account review).

La partie la plus délicate, comme pour tout changement de système, concerne le niveau de personnalisation de la source. Depuis Salesforce.com, il est plutôt simple d’exporter les champs, qu’ils soient standard ou personnalisés.

De son côté, Microsoft Dynamics CRM fournit des cartographies d’import (dans le SDK), facilement réutilisables, qui permettent de gérer la plupart des scénarios de migration de données. Cependant, les objets ou champs personnalisés ne sont pas directement gérés et doivent faire l’objet d’une étude et d’un traitement approfondi. Le degré de complexité de la migration sera donc directement corrélé aux degrés de personnalisation de la source.

Une fois l’ensemble des personnalisations listé, trois cas de figure peuvent être envisagés :

• L’élément source n’existe pas dans le système cible et l’aspect fonctionnel ne peut être reproduit. Dans ce cas particulier, deux options s’ouvrent : l’abandon pur et simple de l’information ou le développement de la même personnalisation dans la cible. C’est souvent l’aspect financier qui va déterminer le choix final (coût du développement vs. ROI).

• L’élément source n’existe pas dans le système cible, mais il existe un moyen – technique ou fonctionnel – de pallier ce manque. Par exemple en associant une entité personnalisée de Salesforce.com à une entité standard de Microsoft Dynamics CRM.

• L’élément source existe dans le système cible mais est incompatible techniquement ou fonctionnement, ou est utilisé pour un tout autre objet (par exemple une entité « compte » dans la source qui désignerait un compte bancaire et la même entité « compte » dans la cible qui désignerait un compte client).

Les personnalisations peuvent également induire des problématiques moins visibles : chez un éditeur de logiciels qui vend également du service, comme cela arrive souvent, une opportunité peut faire référence soit à une vente de produit, soit à une vente de service. Ici, le point d’attention porte sur la disposition (layout) de la page ciblée par une opportunité, qui peut être soit un produit, soit un service. Pour complexifier un peu plus ce cas de figure, chacune de ces dispositions de page peut contenir des champs soit identiques et faisant référence à la même information, soit spécifiques au type d’opportunité… Tout ceci est d’autant plus complexe qu’il n’existe, à ma connaissance, aucun outil pour lister un tel degré de personnalisation. Ce sera donc une tâche ardue qui aura pour objectif de définir le nombre de pages, formulaires et champs à implémenter dans Microsoft Dynamics CRM.

Jusqu’ici, j’ai abordé deux niveaux de personnalisation. Un niveau faible, que je qualifierais de « standard » qui consiste en la création d’entités ou champs en utilisant les possibilités offertes par l’outil. De la configuration en quelque sorte. Ensuite, un niveau « business » qui vise, toujours en utilisant les fonctionnalités natives des outils à créer des éléments destinés à répondre à des besoins métiers plus ou moins complexes (entités, relation, flux de travail, etc.). Chacune de ces personnalisations peut – globalement – être reprise lors de la migration.

Un troisième niveau de personnalisation va quant à lui poser plus de problèmes : les développements spécifiques. Salesforce.com offre des outils de développement propriétaires, avec Apex (langage de programmation fortement typé) mais également un magasin d’applications avec AppExchange, à partir duquel des personnalisations packagées peuvent être installées. Ces éléments ne pourront pas être migrés et devront être traités hors du processus de migration standard (mais évidemment inclus dans le projet de migration).

La mobilité est également un facteur à prendre en compte lors de la migration. Salesforce.com et Microsoft Dynamics CRM proposent chacun leurs propres applications mobiles. Cette partie étant celle ayant une visibilité directe sur l’outil il est important d’en tenir compte dès la phase d’audit. De la même façon, si la solution Microsoft Dynamics CRM est intégrée avec SharePoint et/ou Lync, les connexions avec les différents services sont à étudier (migrer depuis chatter vers Lync par exemple peut poser un vrai problème).