CRM 2011 bis CRM 2016 Migration

Da die Frage sehr weit gefasst ist, sind die Antworten präzise auf den Punkt und gehen nicht in die Tiefe des Themas.

Upgrade von CRM 20XX auf 20YY

Sie können zwar ein direktes Upgrade (vorhandener CRM Server + vorhandene SQL-Datenbank) durchführen, das im Wesentlichen fast so aussieht, als ob Sie ein kumulatives Update anwenden würden, oder einen neuen Server bereitstellen und den vorhandenen SQL-Server verwenden und die von Microsoft empfohlene Methode zum Upgrade besteht darin, ein Migration-Upgrade (neuer CRM-Server +) durchzuführen neuer SQL-Server).

Schritte zur Migration (Kurzgeschichte):

1. Bereitstellen einer neuen CRM-Instanz mit einer neuen SQL Server-Instanz und einer SSRS-Instanz (falls zutreffend)
2. Wenden Sie alle Produktupdates / Rollups / kumulativen Updates an. Sichern Sie die bestehende CRM-Datenbank.
3. Stellen Sie die Datenbank auf der neuen bereitgestellten SQL Server-Instanz wieder her.
4. Verwenden Sie den Deployment Manager, und starten Sie die Organisation importieren Prozess zeigt auf die wiederhergestellte Datenbank, die die startet Aktualisierungsprozess.

Lange Geschichte würde das Upgraden von Plugins mit der neuesten Version des SDK beinhalten (das würde beinhalten, sie zu registrieren, sie zu aktualisieren und alle Plugins und Schritte neu zu registrieren), Authentifizierung, SPNs usw. einzurichten Artikel über eine gute Lesung verknüpft.

Beachten Sie, dass das Upgrade inkrementell erfolgen muss (z. B. 2011 - 2013 - 2015 - 2016, anwendbare KEs dazwischen).

Beste Methode zum Migrieren von Daten von 20XX nach 20YY CRM

Sie müssen keine Daten von 20XX auf 20YY migrieren, wenn Sie die Migrations-Upgrade-Route oder einen unterstützten Upgrade-Pfad verwenden. Es gibt einen Gedankenprozess, dass ein Upgrade versehentlich eine Datenmigration benötigt, aber in Wirklichkeit nicht. Wenn Sie nicht Daten von einem anderen System verschieben oder Ihre bestehende CRM-Datenstruktur ändern (Konsolidierung von Entitäten, Verschieben von Notizen usw.), benötigen Sie höchstwahrscheinlich keine Migration.

Wenn Sie davon ausgehen, dass Sie eines der oben genannten Schritte ausführen müssen, sind einige der am häufigsten verwendeten Integrationstools Scribe für Microsoft Dynamics CRM oder KingswaySoft für Dynamics CRM . Mein Favorit ist KingswaySoft für die einfache Erweiterung und auch das Preismodell (Sie können im Prinzip eine 3-monatige Lizenz erwerben und Ihre Migration durchführen, da Migrationen ein einmaliger Vorgang sind).

Unterschied zwischen CRM On-Prem und CRM Online

Abgesehen von der ganzen Cloud, Lizenzmodell Unterschiede zwischen den beiden, gibt es noch einige Funktionen, die online exklusiv sind (zumindest für den Moment oder bis zum nächsten On-Prem-Update).

Wenn ich zwischen den beiden wähle, ergibt sich meiner Erfahrung nach die Arbeit mit Kunden, die sowohl online als auch vor Ort waren:

1. Vorlaufkosten, laufende Wartung.
2. Vorhandene Infrastruktur (wenn sich ein Unternehmen bereits in einer Cloud befindet) Office 365 würden sie höchstwahrscheinlich mit CRM online gehen).
3. Kontrolle über Upgrades, Datenbanken. On-Prem Kunden sind normalerweise die diejenigen, die mehr Kontrolle über die Datenbanken, Server, wann zu mögen Aktualisierung / Aktualisierung.
4. Features die nur online sind (obwohl Microsoft rollt) die meisten von ihnen gehen auch zu Installationen vor Ort, aber sie kommen eher viel langsamer als bei Online-Instanzen, normalerweise 3-6 Monate). Einige Funktionen wie Innenansicht und Social Listening sind im Moment exklusiv online.

Dynamics 365:

Dynamics 365 ist eine Kombination aus ERP (GP, NAV, AX), Dynamics CRM und einigen Integrationserweiterungswerkzeugen wie Parature. Aus CRM-Sicht wird es nicht anders sein als CRM 2016 online. Nur die Back-End-Datenstruktur, die wahrscheinlich eine einheitliche Größe für alle Modelle sein wird. Obwohl noch weitere Details herauskommen werden, wird es aus Sicht der Funktionalität kein komplett neues Produkt sein. Sie könnten mit ein paar neuen Funktionalitäten aufwarten, wie sie es bei jeder größeren Version tun, aber CRM, wie wir wissen, wird immer noch überwiegend das gleiche sein.

Ich habe viele Migrationen von CRM 2011 zu CRM 201X einschließlich CRM 2016 und Dynamics365 durchgeführt. Hier sind meine gesammelten Vorschläge / Gedanken zu den Problemen

1) Grundsätzlich ist die Organisation Migration, die von CRM Deployment Manager gehandhabt wird, ziemlich gut. Normalerweise erstelle ich eine Staging-Umgebung auf separaten Servern (also CRM 2013 - & gt; CRM 2015 - & gt; CRM 2016), mache eine vollständige Kopie der Datenbank, stelle sie auf dem nächsten Server wieder her und importiere die Organisation mit Deployment Manager. Wie für die Anpassungen - es hängt davon ab, wie alt das CRM ist, wie viele Anpassungen es hat und ob es von CRM 4.0 aktualisiert wurde. Wenn der letzte wahr ist und die Menge der Anpassungen ist riesig - in den meisten Fällen entferne ich alle Javascripts und Plugins und schreibe sie alle von Grund auf neu. Obwohl nach der erfolgreichen Migration zu CRM 2011, nachdem Rollup 12 alle Skripte und Plugins korrekt funktionieren lässt, kann die meiste Logik aus CRM 4.0 normalerweise mit einigen neuen Funktionen von CRM 2016 erreicht werden (nicht nur Business Rules, die ich nicht mag) persönlich, aber meistens Calculated Fields oder Rollup Fields) und es macht keinen Sinn, all das in einigen JavaScript oder Plugins zu behalten. Wenn der Systemursprung CRM 2011 ist, würde ich nur die Funktionalitäten überprüfen, die einfacher gemacht werden können, aber normalerweise nicht das Ganze neu schreiben, nur einige Anpassungen vornehmen. Wenn die Skripts Organisationsaufrufe enthalten, schreibe ich sie normalerweise neu, um webAPI zu verwenden - OrganizationData wird bald aus dem CRM entfernt, also ist das eine gute Sache.

Natürlich würde ich nach dem Importieren der Organisation in die Zielumgebung alle modifizierten Anpassungen anwenden (die in einer separaten DEV-Umgebung erstellt und gründlich getestet wurden).

2) Für solche Zwecke verwende ich immer den Kingswaysoft SSIS Connector. Ich habe alle anderen Tools getestet und dies ist einfach das flexibelste, weil es die ganze Kraft von SSIS-Paketen umfasst und Ihnen einfach einen einfach zu verwendenden Connector bietet. Natürlich ist das meine persönliche Vorliebe, alle Werkzeuge sollten am Ende ihre Arbeit machen.

Wenn ich die Daten zwischen zwei lokalen Umgebungen migriere (normalerweise in der gleichen Domäne), mache ich mir keine Mühe, spezielle Felder wie createdby, modifiedby, statuscode, statusreason usw. zu migrieren. Ich konzentriere mich nur auf Record-IDs. Wenn ich alle Datensätze erstellt habe, aktualisiere ich einfach alle Felder, die mit T-SQL-Skripten problematisch sind, denn das ist viel schneller. Natürlich können Sie das nicht tun, wenn Sie zu Online migrieren, also dauert diese Migration viel länger (und Sie können beispielsweise kein Feld migded migrieren)

Der vereinfachte Fluss, den ich immer verwende, ist so

1. Erstellen Sie alle Datensätze ohne ordnungsgemäße Statuscodes (Standard verwenden) und Nachschlagewerte (da Sie höchstwahrscheinlich den zugehörigen Datensatz nicht haben). Wenn es online ist, dann konzentriere dich auf spezielle Felder, die später nicht mehr geändert werden können - createdon, createdby
2. Aktualisieren Sie alle Suchvorgänge für alle Datensätze (weil nach 1. Sie alle Datensätze in CRM haben)
3. Aktualisieren Sie alle Status, wenn es vor Ort ist, führen Sie alle benutzerdefinierten Skripts aus, die Werte kopieren
4. Übernehmen Sie die Anpassungen

3) Ziemlich gute Antworten wurden bereits gegeben, Dynamics365 ist einfach ein Update für CRM 2016 (deshalb ist es Version 8.2 nicht 9.0), daher gibt es aus CRM-Sicht nicht viele Änderungen. Die größte Änderung, die beim Upgrade berücksichtigt werden kann, ist editierbares Grid - es ist sehr einfach, eine Ansicht zu erstellen, die editierbar ist (obwohl es einen Nachteil hat, wie keine Inline-Datensatzerstellung), was einige Szenarien vereinfachen kann (oder Ihnen erlauben wird) um einige benutzerdefinierte Lösungen zu löschen). Business Process Flows werden besser behandelt, da sie über eine separate Datenbanktabelle verfügen, in der alle wichtigen Informationen über den Prozessstatus gespeichert werden (was auch einen neuen SDK-Zugriff auf diese Prozesse ermöglicht). Andere Dinge sind einfach Kosmetika, hauptsächlich für Geschäftsleute Entwickler.

4) Was die Bounty-Frage anbelangt - alle Apps können immer noch die einfache alte Organization.svc verwenden (indem sie das IOranganizationService-Objekt erhalten), was ein SOAP-Endpunkt für CRM ist. Es gibt keine Pläne, diesen Endpunkt vorerst zu entfernen, daher sehe ich keinen Vorteil beim Umschreiben dieser Anwendung für die Verwendung von webAPI (natürlich ist das möglich). XrmServiceContext ist einfach ein Wrapper über den IOrganizationService, der es Ihnen ermöglicht, ihn in mehr "Unit-of-work" -Weise zu verwenden - sicherlich nützlich zum Abrufen von Daten, aber ich mag ihn nicht, da er zu allen anderen CRUD-Operationen gehört. Aber wie auch immer - es ist immer noch nur ein Wrapper, also ist das einzige, was zählt, wie Sie IOrganizationService erhalten. Zurück in CRM 2011 haben Sie höchstwahrscheinlich das mit der OrganizatoinServiceProxy-Klasse getan, die Sie mit den richtigen Anmeldeinformationen instanziiert haben (wie ich hier erklärt habe: Ссылка ) ). Derzeit wird die Microsoft.Xrm.Tooling.Connector-Assembly als Vorschlag verwendet (Sie können sie einfach von nuget - Microsoft.CrmSdk.XrmTooling beziehen.CoreAssembly) und CrmServiceClient zusammen mit der Verbindungszeichenfolge verwenden (siehe: Ссылка ). Dies ermöglicht es Ihnen, Ihren IOrganizationService zu erhalten, den Sie in xrmservicecontext oder was auch immer Sie wollen, einbinden können. Dieser Ansatz wird vorgeschlagen, da dieses Paket höchstwahrscheinlich in Zukunft webAPI anstelle des Endpunkts Organization.svc verwendet. Wenn Microsoft diesen Dienst entfernt oder nicht mehr verwendet, funktioniert Ihre Anwendung weiterhin problemlos.

Beste Methode zum Migrieren von Daten von 2011 zu clean 2016 CRM.

Ich war vor ein paar Monaten in der gleichen Position wie du für ein Projekt, das ich führe (Lieferung dieses Wochenende).

Nachdem ich ein wenig in diese Lösung eingegriffen habe, kam ich zu der folgenden Schlussfolgerung: Die von Microsoft empfohlene Methode ist schwer zu implementieren, zeitaufwendig und mindert das Risiko nicht, was auch immer. Beachten Sie, dass wir in unserem Fall von On Premise zu Online migrierten, was schwerer zu erreichen ist als On Premise bis On Premise.

In unserem Fall haben wir uns für die Zuordnung der alten vs neuen Datenbank entschieden und alles über ETL-Jobs, die von unserem Integrator konfiguriert wurden, in CRM 2016 Online migriert. Ich glaube, dies ist der beste Weg, da wir die totale Kontrolle darüber haben, was vor sich geht und wenn ein Feld fehlt (Beispiel: Fax für Leads wurde nicht migriert), können Sie einfach nur dieses Feld migrieren.

Wenn Sie das 2011 == & gt; 2013 == & gt; 2015 == & gt; 2016 Road, haben Sie dreifache Arbeit, da Sie jede Lücke zwischen den Versionen abdecken müssen (Beispiel gibt es 4 Felder für Telefon in einer Führung im Jahr 2011 und nur 3 in 2016) und müssen stattdessen mit Lösungen drei Mal kommen von nur einmal.

Unterschied zwischen CRM 2016 und CRM 365 (lokal beide)

Keine für das CRM. Wenn ich mich nicht irre, kann die 365-Version mit serverseitiger Synchronisation das 365-Plugin für Outlook verwenden, das viel mehr Funktionen als die andere Version hat ziemlich ähnlich dem 2011). Edit: Ich habe mich geirrt. Dynamics 365 ist der neue Name von CRM 2016 (nach dem neuen 365-Branding von Microsoft, das auch auf Dynamics AX angewendet wurde). Ihr System sollte bereits aktualisiert sein und neben der Namensänderung (und dem brandneuen Outlook Add-on, das ich noch nicht getestet habe), haben Sie Voice of the Customer in das System integriert, anstatt als Lösung zu kommen. Ich denke, es gibt noch einige andere Änderungen. Beachten Sie, dass Sie Ihre Lösungen wie "Außendienst" manuell über die Administrationsoberfläche aktualisieren müssen.

Migrationsplan:

Da die Frage für Bounty nominiert war, werde ich die Schritte, die ich während der Aktualisierung von 2011 bis 2016 unternommen habe, teilen (obwohl ich nicht die offizielle Quelle bin, kann es hilfreich sein).

1. Ich hatte die Registrierung aufgehoben und folgende Anpassungen gelöscht: Javascript Bibliotheken, HTML und Silverlight (xap) Web-Ressourcen, Plugins, Lösungen, Workflows.
2. Dann hatte ich meine Datenbank Schritt für Schritt aktualisiert. Ich hatte 3 VMs mit verschiedenen CRM-Versionen installiert: 2013, 2015 und 2016. Als ich schließlich meine Organisation in CRM 2016 importierte und die Überprüfungen durchführte - wurden alle Daten genau aktualisiert.
3. Dann habe ich meine Anpassungen überarbeitet und aktualisiert (was in Schritt 1 gelöscht wurde). Schließlich habe ich sie in der Staging-Umgebung getestet.

Was ist mit Anpassungen upgraden:

1. 80% des js-Codes wurden durch das neue Feature ersetzt, das 2013 eingeführt wurde - Business Rules. Sie helfen bei der Sicherheit auf Feldebene: Wenn wir brauchen, können wir ein Feld basierend auf einer bestimmten Bedingung oder dem Zustand eines anderen Feldes verstecken / sperren.
2. .net-Anpassungen: Workflow-Aktivitäten, Plugins, benutzerdefinierte Anwendungen bleiben unverändert. Der gesamte Code aus der Version 2011 wird 2016 unterstützt (der Code von CRM 4 wird jedoch nicht unterstützt).
3. 50% der Workflows wurden als Plugins implementiert, als schnellere und robustere Lösung.

Nun zur Frage der Kopfgelder:

Die Zusammenarbeit mit xrmservicecontext und dem Organisationsservice hat sich nicht wesentlich geändert.

Stellen Sie sicher, dass Sie keine Verweise auf CRM 4-DLLs haben, ersetzen Sie dann einfach alle Ihre CRM SDK-Verweise durch ihre 2016-Version (ich empfehle die Verwendung von nuget-Paketen anstelle von direkten Assemblierungsverweisen). Dein Code sollte ohne Fehler kompilieren.