SuiteCRM 7 naar 8: checklist vóór de overstap
- SuiteCRM 8 is geen klikupgrade op dezelfde installatie van 7 – de officiële route is een migratieproces met eigen pakketlogica en integratie van oudere onderdelen.
- De meeste vertragingen ontstaan door een onvolledige inventaris (pakketten, hooks, integraties) en ontbrekende realistische stagingtests.
- Livegang zonder gedocumenteerd terugdraaiplan en inhoudelijke acceptatiecriteria is een organisatorisch risico, geen zuiver IT-onderwerp.
Migratiecomplexiteit grof inschatten
Geen urenorakel – een filter om te bepalen of u eerder standaardwerk of projectwerk kunt verwachten.
Focus op inventaris, staging en inhoudelijke acceptatie. Gestructureerde tools kunnen helpen – maar vervangen geen tests.
De overstap van SuiteCRM 7 naar 8 is voor veel organisaties onvermijdelijk zodra ondersteuning, PHP-stack of productstrategie dat vereisen. Tegelijk is het geen routinepatch. Officiële documentatie en migratiepakketten maken duidelijk: het gaat om een gestructureerde overgang, niet om ‘installatiebestand overschrijven en hopen’.
Deze tekst is een voorbereidings- en beslischecklist. Deze vervangt geen projectplan of bindende uitspraak over uw concrete codebasis.
1. Architectuur: waarom 7 en 8 anders aanvoelen
SuiteCRM 8 brengt een gemoderniseerde applicatiearchitectuur en interfacelaag mee; oudere onderdelen en migratieroutes maken deel uit van het officiële model. Voor beslissers betekent dit praktisch:
- Verwachtingen rond interface, navigatie en beheerwegen veranderen.
- Aanpassingen uit 7.x werken niet automatisch één op één.
- Beheer (PHP-versie, Composer-/consolestappen, cache, rechten) volgt de releaseopmerkingen van de doelversie.
Wie ‘alleen functies wil vergelijken’, onderschat het aandeel migratievakwerk.
2. Kaders vaststellen vóór de techniek start
- Leg de doelrelease (bijvoorbeeld een concrete 8.x-lijn) schriftelijk vast – niet ‘iets actueels’.
- Bedrijfsaanleidingen: beveiliging, einde PHP-ondersteuning, ontbrekend 7.x-onderhoud, strategische interface – met prioriteiten.
- Onderhoudsvenster en communicatieplan voor vakafdelingen.
- Rollen: wie beslist go/no-go, wie test inhoudelijk, wie levert de host?
- Terugdraaivoorwaarde: bij welk foutbeeld wordt teruggedraaid – en hoelang is de back-up geldig?
3. Inventaris – het deel dat teams het vaakst onderschatten
3.1 Pakketten en maatwerkcode
Maak een lijst van geïnstalleerde pakketten met versie en laatst bekende stand. Markeer: productie / optioneel / ongebruikt. Voeg logic hooks, schedulertaken, maatwerkmodules en ‘kopieerwerk in custom/’ toe dat nooit een pakket was.
3.2 Integraties
SSO, ERP, marketing, telefonie, documentbeheer, BI-exports: elke interface heeft een eigenaar en een testgeval na de migratie nodig.
3.3 Gegevenskwaliteit
Duplicaten, kapotte relaties, verweesde bijlagen – migratie vergroot bestaande gegevensproblemen zelden vanzelf; ze maakt ze zichtbaar en vertraagt acceptatie.
4. Staging: wat ‘getest’ zou moeten betekenen
Een lege demo-installatie bewijst weinig. Minstens:
- Kopie met een realistische gegevensselectie of volledige kopie – bewust beslissen en documenteren.
- Migratie volgens de officiële route van de gekozen pakketlijn (niet ‘forumgeruchten’ als draaiboek).
- Testscript: aanmelding, rechten, een kernverkoopproces, e-mail in/uit, een rapportage, een kritiek maatwerkproces, bijlage openen.
- Prestatiesteekproef bij modules met veel lijstgegevens – subjectief, maar vroeg waarschuwend.
Bekende problemen uit de documentatie (rechten na CLI-opdrachten, CSRF/sessies na een herhaalde migratie op dezelfde URL, verkeerd pakket in plaats van migratiepakket) horen in het draaiboek, niet als verrassing tijdens het livegangweekend.
5. Gegevens, bestanden, omschakeling
- Database- en bestandsvolume ingeschat; back-upduur gemeten, niet geschat.
- Bijlagen: steekproef vóór/na – openen, niet alleen ‘bestand staat er’.
- Omschakelvolgorde: onderhoudspagina, definitieve synchronisatiestrategie, DNS/URL, sessies/cookies, eerste rooktests.
- Extra nazorg: 3–5 dagen duidelijk aanspreekpunt, bekende tijdelijke oplossingen, escalatieroute.
SuiteMigrate ondersteunt gestructureerde overnames en mappingscenario’s in de AgenticUltimate-context. Het neemt inhoudelijke acceptatie of verantwoordelijkheid voor maatwerkcode niet van u over – maar kan de technische route gedisciplineerder maken dan ad-hocscripts. Geschiktheid hangt af van bronsysteem en gegevensomvang.
SuiteMigrate ↗6. Criteria voor livegang (voorstel)
Leg vooraf vast, niet achteraf:
- Alle A-processen groen op staging
- Geen openstaande ‘onbekende’ A-pakketten zonder plan
- Back-up + herstelproef gedocumenteerd
- Inhoudelijke goedkeuringen van proceseigenaren
Urenbesparing en ‘succespercentages’ zonder verband met uw codebasis zouden speculatief zijn – daarom ontbreken ze hier bewust.