Skip to main content

Welche Daten werden bei der Migration übertragen?

KIX 18 fragt die zu migrierenden Inhalte aktiv bei der KIX 17 Instanz ab. Die abgeholten Inhalte werden an die Strukturen (z. B. neue IDs) von KIX 18 angepasst.

Nachfolgend aufgeführte Daten werden übertragen. Individuelle in KIX 17 verwendete Attribute und Systemergänzungen werden nicht übertragen. Wenden Sie sich dazu bitte an unseren Support.

  • Konfigurationsdaten

    • Ticketstatus

    • Tickettypen

    • Queues/Teams (die Signaturen werden inkludiert)

    • Konfigurationen von Dynamischen Feldern

    • General Catalog Klassen

    • Asset-Klassendefinitionen

  • Geschäftsdaten

    • Organisation

    • Kontakte (Customer User)

    • Kontakte (Agent User)

    • Assets (Config Items) inkl. Versionen

    • FAQs inkl. Anhänge

    • SLAs

    • Tickets

      • Artikel inkl. Anhänge

      • Tickethistorie

      • Dynamische Felder

    • Ersetzung der IDs

      • Die IDs aus KIX 17 werden in KIX 18 durch neue IDs ersetzt.

    • Verknüpfungen

      • Assets zu Tickets

      • Assets zu Assets

    • Services (KIX Pro)

      • Assets der Klasse "Service"

Hinweise zu den übertragenen Daten

Ticketdaten

Nach der Migration sind alle Tickets der Quellumgebung in der Zielumgebung vorhanden, einschließlich ihrer Eigenschaften:

  • Artikel: alle Artikel inkl. Anhänge und jeweiliger Kanal

  • Historie: Einträge in der Tickethistorie verweisen auf die migrierten Objekte.

  • Zeit-Einträge: Die am Ticket erfassten Zeiten werden migriert.

  • Sperrstatus: Tickets, die ein Nutzer gesperrt hat, sind für ihn auch in KIX 18 gesperrt.

  • Ticket-Status und -Typen: In der Zielumgebung neu erzeugte Status und Typen werden nach der Migration ungültig gesetzt.

    Die Deaktivierung von Status und Typen erfolgt, weil Ticketstatus-Workflows nicht mehr existieren und die alten Werte zunächst nur aus Gründen der Abwärts-/Historienkompatibilität abgerufen werden.

  • Priorität: Für folgende Quell-Prioritäten wird ein Mapping angewandt:

    Quelle (KIX 17)

    Ziel (KIX 18)

    1 very low

    5 very low

    2 low

    4 low

    3 normal

    3 normal

    4 high

    2 high

    5 very high

    1 very high

Textbausteine

Nach der Migration sind die Textbausteine der Quellumgebung in der Zielumgebung vorhanden.

  • Das Migrationsskript entfernt nicht mehr benötigte Datenbank-Strukturen (Spalten).

  • Die Kategorien der KIX 17-Textbausteine werden in den Schlagworten der KIX 18-Textbausteine hinterlegt.

    • Die Bezeichnungen der Kategorie-Ebenen werden als einzelne Schlagworte erfasst.

    • Leerzeichen werden durch einen Unterstrich ("_") ersetzt.

  • Die Platzhalter-Teilstrings "<ORTS_" werden durch "<KIX_" ersetzt.

    Hinweis

    Die Gültigkeit von Platzhaltern wird nicht verifiziert.

  • Die den Textbausteinen zugeordneten Typen und Queues werden bei der Migration mit übertragen. Queues in KIX 17 werden in KIX 18 zu Teams migriert.

  • Textbausteine enthalten in KIX 18 keine Betreffzeilen mehr.

Verknüpfungen

  • Nach der Migration sind alle Verknüpfungen der Quellumgebung in der Zielumgebung vorhanden.

    • Config-Items zu Tickets

    • Config-Items zu Config-Items

    • Config-Items zu FAQs

    • Tickets zu Tickets

    • Tickets zu FAQs

  • Nicht vorhandene bzw. nicht zulässige Verknüpfungstypen werden durch "Relevant To" ersetzt.

  • Führen Sie ggf. den Konsolenbefehl Admin::Installation::Migrate::Ticket::SetAffectedAssetFromLinks aus, um die verknüpften Assets am Dynamische Feld Betroffene Assets zu hinterlegen.

Queues/Teams

  • Nach der Migration sind alle "Queues" der Quellumgebung als "Teams" in der Zielumgebung vorhanden.

  • Die Struktur der Queues findet sich in Teams wieder (Ober-/Unterqueues).

  • Die Signaturen der Quellumgebung sind an den Teams hinterlegt.

    • ältere Platzhalter der Art <OTRS_xyz...> wurden ersetzt durch <KIX_xyz...>

      Gegebenenfalls sind nicht alle Platzhalter kompatibel und erfordern eine manuelle Nachkontrolle und Anpassung.

CI-Klassendefinitionen

  • Nach der Migration sind alle "CI-Klassendefinitionen" (inkl. aller Versionen) der Quellumgebung als "Asset Klassendefinitionen" der Zielumgebung vorhanden.

    • Existiert in KIX 18 bereits eine Klasse des gleichen Namens, erhält die Migrationsklasse das Prefix "Migration-".

  • Nicht mehr unterstütze CI-Attributtypen werden als Attribute des Typs "Text" dargestellt.

  • Nach der Migration liegen die vormals vorhandenen CI-Attribute vom Typ "EncryptedText" im KIX als "Text" vor.

    Warnung

    Dadurch werden darin hinterlegte Passwörter für Nutzer mit Berechtigungen auf die Assets sichtbar.

    Festlegung hinsichtlich der zu verschlüsselnden Attribute können Sie SysConfig-Schlüssel ITSM::ConfigItem::XML::Type::Text###EncryptedText treffen.

  • Zur Aufnahme der nicht-versionierten CI-Attachments aus KIX 17 erhält jede Assetklasse zusätzlich das Attribut "CIAttachments" (letztes Attribut) des Typs "Attachment".

    ci-klassendefinition_attributtyp-ciattatchment.png

  • An Feldern, deren Typ-Attribut nicht identisch zu dem in KIX 17 ist, gibt es in KIX 18 ein weiteres Attribut "MigratedType" mit dem jeweiligen Wert des Typ-Attributs aus KIX 17.

    ci-klassendefinition_attributtyp-migratettype.png

  • Perl-Kommentare im String der Klassendefinition gehen verloren, da der String in eine Perl-Struktur und nach der Anpassung zurück zu einem String gewandelt wird. Dabei gehen die Kommentare verloren.

    Anmerkung

    zu Korrekturen bei Migrationen ausgehend von KIX 17.19 (oder niedriger) oder zu KIX 18 v24 (oder niedriger):

    Sollten nach der Migration keine Archiv-Versionen der Assets angezeigt werden, kann dies durch Anwendung folgenden DB-Statements auf der KIX 18-Datenbank korrigiert werden.

    UPDATE xml_storage 
SET xml_type = REPLACE( xml_type, 'ITSM::ConfigItem::Archive:', 'ITSM::ConfigItem::Archiv:') 
WHERE xml_type LIKE 'ITSM::ConfigItem::Archive:%';

Config Items/Assets inkl. Versionen

CustomerCompany/Organisationen

  • Das Objekt "CustomerCompany" in KIX 17 wird zu "Organisation" in KIX 18.

  • Die Attribute der "CustomerCompany" in KIX 17 werden in KIX 18 zu folgenden Attributen:

    KIX 17 CustomerCompany Attribute

    KIX 18 Organisation Attribute

    CustomerCompanyCity

    City

    CustomerCompanyComment

    Comment

    CustomerCompanyCountry

    Country

    -

    ID (wird bei Übertragung erstellt)

    CustomerCompanyName

    Name

    CustomerID

    Number

    CustomerCompanyStreet

    Street

    CustomerCompanyURL

    URL

    ValidID

    ValidID

    CustomerCompanyZIP

    Zip

Ansprechpartner/Nutzer

  • Nach der Migration sind alle "CustomerUser" der Quellumgebung als "Kontakte" ("IsCustomer") in der Zielumgebung vorhanden.

    • Nutzung SSP ist aktiviert,

    • Rollenzuordnung "Customer" vorhanden

    • PW-Hash-Übernahme

  • Nach der Migration sind alle "Agent User" der Quellumgebung als "Kontakte" und "Nutzer" ("IsCustomer" && "IsAgent") in der Zielumgebung vorhanden.

    • Rollenzuordnung "Customer" vorhanden

    • Rollenzuordnung "Agent User" vorhanden

    • Passwort-Hash-Übernahme ist erfolgt

    • Existiert in KIX 18 bereits der Login-Name eines KIX 17-Nutzers (Agent), wird er als neuer Nutzer mit dem Suffix "-migrate" angelegt (ähnliches wie bei Assetklassen).

  • Bei Migration einer KIX 17-Umgebung zu KIX 18 wird der Systemnutzer aus KIX 17 (UserID 1, i.d.R. "root@localhost") nicht migriert.Stattdessen werden alle seine Zuordnungen auf den Systemnutzer der KIX 18-Umgebung (Log-in: "admin") übertragen, d.h:

    • Tickets, die in KIX 17 dem Verantwortlichen bzw. Bearbeiter "root@localhost" zugeordnet sind, sind in KIX 18 dem Nutzer "admin" zugeordnet.

    • In der Historie von Tickets bzw. Assets wird ebenfalls statt "root@localhost" der Nutzer "admin" referenziert.

  • Das Objekt "CustomerUser" in KIX 17 wird zu "Nutzer" bzw. zu "Kontakt" in KIX 18.

  • Die Attribute von "CustomerUser" in KIX 17 werden in KIX 18 zu folgenden Attributen:

    KIX 17 CustomerUser Attribute

    KIX 18 Nutzer/Kontakt Attribute

    -

    Contact.AssignedUserID

    (Wird bei Übertragung erstellt (User.ID))

    UserCity

    Contact.City

    UserComment

    Contact.Comment

    UserCountry

    Contact.Country

    UserEmail

    Contact.Email

    UserFax

    Contact.Fax

    UserFirstname

    Contact.Firstname

    -

    Contact.Fullname

    UserLastname

    ValidID

    UserMobile

    Contact.Mobile

    UserCustomerID

    Contact.PrimaryOrganisationID

    (Erfordert Lookup auf Organisation.ID via Organisation.Shortname)

    UserCustomerIDs

    Contact.OrganisationIDs

    (Erfordert Lookups auf Organisation.ID via Organisation.Shortname)

    UserPhone

    Contact.Phone

    UserStreet

    Contact.Street

    UserTitle

    Contact.Title

    -

    Contact.UserID

    ValidID

    Contact.ValidID

    UserZip

    Contact.Zip

    -

    Contact.ID

    (Wird bei Übertragung erstellt)

FAQ inkl. Anhänge

  • Nach der Migration sind alle FAQ-Kategorien der Quellumgebung in der Zielumgebung vorhanden.

  • Ist im Quellsystem eine Sprache referenziert, die in der Zielumgebung nicht vorhanden ist, wird diese im Zielsystem eingerichtet.

  • Inhalte von FAQ-Artikeln, die im Quellsystem standardmäßig als Symptom, Ursache, Lösung und Kommentar verwendetet werden, sind lesbar im Zielsystem vorhanden.

  • Erhalten bleiben:

    • Richtext-Formatierung

    • Inline-Bilder

    • Attachments am FAQ-Artikel

  • Die Kennzeichnung als "public" oder "external" im Quellsystem führt zum Setzen des Flags "Im SSP anzeigen".

  • Die FAQ-Bewertungen können entfallen.

Dynamische Felder

  • Nach der Migration sind folgende Daten Dynamischer Felder in der Zielumgebung vorhanden:

    • Konfigurationen

    • die in den Dynamischen Feldern enthaltenen Werte

    • Verweisdaten

  • Checklisten:

    • Dynamische Felder vom Typ "Checklist" sind nach der Migration in "MobileProcessingChecklist[n]" abgebildet

    • Mapping der Werte (KIX 17 => KIX 18):

      • closed => OK

      • notok => NOK

      • pending => pending

      • open => -

    • Übertragen werden nur Titel und Status der Checklisteneinträge; die Beschreibung wird nicht übertragen. Die Übertragung der Status beschränkt sich auf die Checklisten-Status von KIX 18.

  • Dynamische Felder nicht unterstützter Feldtypen

    • werden im Zielsystem deaktiviert ( auf "ungültig" gesetzt)

    • erhalten im Label das Suffix "- DF Type not yet supported!".

    • Nach Klick öffnet sich der Bearbeiten-Dialog und zeigt einen Hinweis an.

Mapping Dynamischer Felder vom Objekttyp "Ticket"

Dynamische Felder vom Objekttyp "Ticket" werden wie folgt gemappt. Sie werden in KIX 18 dem Objekttyp "Ticket" zugeordnet :

Feldtyp in KIX 17

Feldtyp in KIX 18

Gültigkeit nach Migration

Attachment

Text

ungültig

Captcha

wird nicht  migriert!

Checkbox

Selection

gültig

Date

Date

gültig

DateTime

DateTime

gültig

Dropdown

Selection

gültig

DropdownGeneralCatalog

Selection

ungültig

ITSMConfigItemReference

AssetReference

gültig

Multiselect

Select

gültig

MultiselectGeneralCatalog

Select

ungültig

ObjectReference/CustomerCompany

Organisationsverweis

gültig

ObjectReference/CustomerUser

Kontaktverweis

gültig

ObjectReference/User

Kontaktverweis

gültig

RemoteDB

Selection

ungültig

(Manuelle Änderung auf DataSource (ggf. auch Einrichtung DataSource undConnection) erforderlich.)

RichText

Text

ungültig

SingleSelection

Selection

gültig

Text

Text

gültig

TextArea

TextArea

gültig

Token

Text

ungültig

Mapping Dynamischer Felder vom Objekttyp "FAQ"

Dynamische Felder vom Objekttyp "FAQ" werden wie folgt gemappt. Sie werden in KIX 18 dem Objekttyp "FAQ" zugeordnet :

Feldtyp KIX 17

Feldtyp in KIX 18

Gültigkeit nach Migration

TextArea/FAQ

TextArea

gültig

Mapping Dynamischer Felder vom Objekttyp "Article"

Dynamische Felder vom Objekttyp "Artikel" werden wie folgt gemappt. Sie werden in KIX 18 dem Objekttyp "Artikel" zugeordnet :

Feldtyp KIX 17

Feldtyp in KIX 18

Gültigkeit nach Migration

Attachment

Text

ungültig

Captcha

wird nicht  migriert!

Checkbox

Selection (Multiselect)

gültig

Date

Date

gültig

DateTime

DateTime

gültig

Dropdown

Selection

gültig

DropdownGeneralCatalog

Text

wenn KIX Connect installiert: DataSource

ungültig

ITSMConfigItemReference

AssetReference

gültig

Multiselect

Select

gültig

MultiselectGeneralCatalog

Text

wenn KIX Connect installiert: DataSource

ungültig

ObjectReference/CustomerCompany

Organisationsverweis

gültig

ObjectReference/CustomerUser

Kontaktverweis

gültig

ObjectReference/User

Kontaktverweis

gültig

RemoteDB

Text

wenn KIX Connect installiert: DataSource

ungültig

RichText

Text

ungültig

SingleSelection

Selection

gültig

Text

Text

gültig

TextArea

TextArea

gültig

Token

Text

ungültig

General Catalog

  • Nach der Migration sind alle Werte aller General Catalog Klassen der Quellumgebung in der Zielumgebung vorhanden.

  • In der Zielumgebung bereits vorhandene General Catalog Klassen werden um zusätzliche Auswahlwerte der Quellumgebung ergänzt.

  • Kommen aus dem Quellsystem Einträge an, die schon bestehen, werden diese belassen, aber die Referenzen in den eingehenden Daten entsprechend "umgehängt".

Service-Daten

  • Für KIX Pro Nutzer: Nach der Migration sind alle Service-Einträge als Assets der Klasse "Service" in der Zielumgebung vorhanden

  • Der Eintrag "Zugeordnetes Team | Assigned Queue" wird nicht übernommen.

  • Kritikalität wird wird aktuell nicht übernommen.

  • es erfolgt keine Migration der vorhandenen Daten in Klasse "Service"

SLA

  • Nach der Migration sind alle SLAs der Quellumgebung in der Zielumgebung vorhanden.

  • Die SLA-Erfüllungszeiten werden aus der Zielumgebung in die Quellumgebung übertragen. Die Angaben zu SLA-Verletzung (ja/nein) und SLA-Abweichung (Zeitdauer) basieren auf KIX 18 Berechnungen, ausgehend vom  Erstell-/Erfüllungszeitpunkt.

  • SLA-Startzeitberechnungen auf Basis eines Dynamischen Feldes (DateTime) werden nicht betrachtet, es gilt der Erstellzeitpunkt des Tickets.

  • Die SLA-Eigenschaften "Typ" und "Aktualisierungszeit" entfallen.

  • Ist im Quellsystem ein Kalender referenziert, welcher in der Zielumgebung nicht vorhanden ist, verwendet das Zielsystem den Standardkalender.

In diesem Abschnitt: