Een systeemmigratie betreft de verhuizing van 1 systeem, naar een ander systeem. De migratie naar een nieuw systeem kan allerlei redenen hebben. Het bestaande platform is bijvoorbeeld verouderd en voldoet niet meer aan de huidige business vereisten of er is een performanter systeem nodig doordat de organisatie gegroeid is. Een systeemmigatie is complex en heeft standaard het gevaar te falen: gebruikers zijn immers gewend met het oude platform en nieuwe technologie wordt niet altijd direct omarmd. Een systeemmigratie betreft daarnaast altijd veel (complexe) data die behouden dient te blijven. Soms is een systeemmigratie daarom complexer dan de bouw van een volledig nieuwe infrastructuur.
Een succesvolle migratie bestaat uit enkele belangrijke stappen, waarbij we er vanuit gaan dat er al een volledige functionele analyse van de nieuwe situatie reeds is uitgevoerd.
De migratie begint met een volledige analyse van uw huidige platform en een beschrijving van de benodigde veranderingen. Op basis daarvan zal de nieuwe omgeving worden geinstalleerd en geconfigureerd. Na een initiële migratie van de data uit de live-omgeving, kan u de nieuwe omgeving functioneel testen.
Na een eerste functionele test en een beschrijving van de ervaring uit de initiele migratie, zal het migratieplan worden opgesteld en de nieuwe omgeving worden geschoond van klantgegevens en met demo data worden gevuld. Op dit moment begint de benodigde ontwikkeling van het beoogde platform, waarbij ook de benodigde (bestaande) koppelingen met derden worden herzien. Deze koppelingen dienen vooral voldoende gedocumenteerd te zijn, zodat daar feilloos op kan worden voortgewerkt.
Wanneer de nieuwe omgeving gereed is conform de functionele vereisten, wordt er een datamigratietest uitgevoerd. De huidige database(s) worden gematcht met de toekomstige database(s), en wordt een back-up gemaakt van uw volledige omgeving en de bestaande database worden tot slot geimporteerd in de nieuwe (test) omgeving. Wanneer dit foutloos is voltooid, zal er een definitieve datum voor de switch van het platform worden aangeduid.
SAMENGEVAT
Een systeemmigratie betreft de verhuizing van 1 systeem, naar een ander systeem. Bijvoorbeeld omdat het bestaande platform is verouderd en niet meer aan de huidige business vereisten voldoet. Een systeemmigratie omvat altijd veel (complexe) data die behouden dient te blijven. De migratie begint daarom met een volledige analyse van uw huidige platform en een beschrijving…
EMAKERS heeft reeds verschillende systeemmigraties met succes afgerond, waaronder de migratie van Magento 1 en Shopware 5 naar Shopware 6, de migratie van Woocommerce en Lightspeed naar Shopify en de migratie van SAP naar Exact Online.
Tenminste twee weken voor de migratie naar een nieuw platform vragen wij toegang met beheerdersrechten tot uw bestaande omgeving. Reken daarvoor op zo’n 4 uur noodzakelijke ondersteuning van uw bestaande leverancier. Vanaf dat moment zal uw bestaande leverancier mogelijkerwijs ook geen urgente support en garantie meer geven.
Op de dag dat de nieuwe omgeving live gaat zal er binnen enkele uren nieuwe verbindingen moeten worden gemaakt en kan het zijn dat uw omgeving enige tijd niet bereikbaar is. Er is onder meer een afhankelijk van derden, zoals de beheerder van uw domeinnaam (uw domain name server). Een degelijke aanpak zal deze risico’s echter tot een absoluut minimum beperken. Indien noodzakelijk, kan een migratie daarom tegen meerkost ook in het weekend of in de late avond worden uitgevoerd.
Binnen het World Wide Web bestaan zogenaamde Domain Name Servers (DNS) om iemand naar de juiste server te leiden. Live gaan op een nieuwe webtoepassing betekent in de praktijk meestal het omleiden van de DNS naar de juiste server. Uw nieuwe gegevens worden doorgegeven aan de DNS, waarna uw vernieuwde toepassing al binnen enkele minuten verkeer ontvangt en de meeste internetters al binnen enkele uren naar de vernieuwde toepassing worden geleid. Officieel kan het echter tot 48 uur duren voordat uw toepassing toegankelijk is op uw nieuwe systeem, van Siberië tot Chili. Dit kan betekenen dat zowel uw oude als uw nieuwe omgeving parallel enkele dagen online moeten blijven. Na het omleiden van de domeinnaam naar de nieuwe server, zal de eerste prioriteit zijn om deze te markeren als een ‘veilige’ server van een ‘bekende’ leverancier. Dit gebeurt door het aanvragen van een zogenaamd SSL-certificaat (SSL staat voor Secure Socket Layer).
Nadat u live bent op uw nieuwe platform en uw vernieuwde productieomgeving in hoog tempo is doorgetest, doen wij de nodige handelingen op het gebied van zoekmachinemarketing en een nauwgezette monitoring gedurende minimaal 72 uur om aanvullende prestatieverbeteringen te realiseren.
Wij adviseren u om de eerste drie werkdagen na migratie geen grote commerciële acties (mailings, above the line communicatiecampagne) uit te voeren om zorgvuldig het nieuwe systeem in normale status te kunnen monitoren.
Contentmigratie bij replatforming
Bij de migratie naar een nieuw platform spelen content en data een grote rol. Migratie naar een nieuwe website of webshop gaat soms ook gepaard met een vernieuwing van de digitale huisstijl. De content van de oude webshop voldoet niet meer aan de gewenste content en moet aangepast worden. Begin daarom tijdens de migratie al met het ontwikkelen van nieuwe content.
Speciale aandacht voor SEO bij migratie website of webshop
Betreft een systeemmigratie een website of webshop, dan moet er specifieke aandacht gaan naar SEO. Immers: Google wist u waarschijnlijk al te vinden en u wilt dat die opgebouwde autoriteit behouden blijft. Doet u niets, dan krijgen klanten na livegang van een nieuw e-commerceplatform waarschijnlijk 404 foutmeldingen wanneer zij via Google bij u terechtkomen. Dit betekent dat een opgevraagd internetadres (URL) niet gevonden kan worden, waardoor u grote hoeveelheden verkeer en omzet misloopt.
Wanneer u replatformt, dan veranderen de URL’s van pagina’s vaak. Zoekmachines hebben oude URL’s opgenomen in hun index, waardoor de gebruiker naar verwijderde of gewijzigde pagina’s wordt geleid en deze 404 foutmeldingen ziet. Dit kan worden voorkomen door het opstellen van redirects: verwijzingen van de ene naar de andere URL. Deze verwijzingen installeren we via instructies (een klein .htaccess bestand in de hoofdmap van de server) aan Google en andere zoekmachines, waarin staat dat het oude internetadres nu op een nieuw adres te vinden is. Zoekmachines zullen meestal dan hun indexering dienovereenkomstig aanpassen.
Na installatie van de juiste instructie, is het ook van belang om de belangrijkste zoekmachiens van de juiste (aangepaste) sitemap te voorzien via Google Search Console en Bing Webmasters. Tot slot schakelen we een automatische webpaginacrawler in, die ook nog eens actief naar eventueel gebroken links zoekt.
Klantcommunicatie na livegang nieuwe website of webshop
Het zien van een nieuw platform kan door gebruikers verschillende (negatieve) reacties uitlokken. Heb ik wel de goede site ingetypt? Is de site gehackt? Hierdoor kunnen zij bijvoorbeeld afwachtend zijn met het plaatsen van een bestelling. Begeleid ze daarom nauwkeurig om de acceptatie van het nieuwe platform te versoepelen. Geef ze bijvoorbeeld instructies over de werking van het nieuwe platform.
De functionele specificaties worden doorgaans opgesteld nadat de business requirements zijn opgesteld. De functionele specificaties zijn een uitwerking, per functie, van de opgestelde vereisten.
Een functionele specificatie is een beschrijving van de werking of functies waaraan een webtoepassing moet voldoen. Aan de hand van deze specificatie kunnen ontwikkelaars de gevraagde toepassing realiseren. In de functionele specificatie staat onder meer de scope van het systeem, de gebruikersrollen en bijbehorende rechten, eventuele koppelingen met derde systemen, enzovoort.
Een functionele specificatie geeft het gewenste gedrag van een systeem weer. Niet-functionele vereisten zijn bijvoorbeeld kwaliteitseisen of de prestatie waaraan een systeem moet voldoen.