Skift af BC eller NAV-partner

Det her er et af de emner de andre partnere ikke skriver om. Af forståelige grunde. Men vi sidder alligevel med det fra tid til anden, så lad os snakke om det:

Ikke alle partnerskaber holder. Når responstiderne er lange, dokumentationen mangler eller projekterne aldrig lander, er det tid til at overveje noget andet.

Det typiske forløb er, at det ikke er én ting. Det er summen. En ticket der har ligget tre uger uden svar. En go-live der ryger et halvt år fordi testmiljøet ikke er klar. En udvikler der var god, men rejste, og den næste kan ikke finde tilbage til hvad der var bygget. En faktura der ikke matcher et estimat ingen husker at have godkendt. Et krav der blev lovet i salgssamtalen for tre år siden og som stadig ikke er leveret.

Hver enkelt ting er til at leve med. Tilsammen er de et signal.

De fleste venter for længe. Dels fordi det er ubehageligt at erkende. Dels fordi der ligger en bekymring om, hvad det koster at skifte, og om den nye partner bare er et nyt sæt af de samme problemer.

Vores første skridt er ikke et skifte. Det er en vurdering.

Først en ærlig vurdering af løsningen som den står

Vi åbner tenanten, læser extensions, kører en discovery over dimensioner, integrationer, jobs, brugerroller og den tekniske gæld der er ophobet. Vi læser jeres tickethistorik, hvis vi må. Vi taler med to-tre nøglebrugere om, hvor de oplever at systemet kæmper imod dem. Det tager typisk en uge. Vi kommer tilbage med et notat, der siger hvad der virker, hvad der er skrøbeligt, og hvad der skal fixes som det første.

Ofte er løsningen bedre end I tror. Og ofte er der ting der bør gøres anderledes, men som ikke har noget at gøre med hvem der har bygget det. Det er bare tid til at rydde op. Den slags siger vi først, før vi foreslår noget nyt.

Hvis I efter vurderingen vælger at skifte, ligger der nogle praktiske skridt der skal håndteres ordentligt.

Den nuværende partner bliver orienteret af jer, ikke af os

I får hjælp til at formulere opsigelsen, overlevering af source, kildekode til extensions, nøgler, service principals, godkendte tenant-settings, og en tjekliste til hvad I skal sikre, inden I slipper den gamle aftale. Vi skriver kontrakten om eksisterende service- og SLA-aftaler sammen med jer, så I ikke ender i et vakuum.

Det vi konkret beder om afhænger af, om I står på NAV eller på Business Central. Begge dele er standard ved partnerskifte, men også åbenlyst for den part der skal levere det, så jo tidligere I beder om det, jo nemmere flyder processen.

Hvis I er på NAV

Vi beder typisk jeres nuværende partner om kildekoden i FOB- og TXT-format, gerne som én samlet eksport, sammen med en objektoversigt der viser versionsnummer og modificeret-flag per objekt. Den specifikke NAV-version og CU-niveau skal frem. Licensfilen (.flf) eller en license information-udskrift fortæller os hvilke granules og brugertyper jeres setup dækker, og hvem licensen er udstedt til. Derefter en SQL-backup af produktionsdatabasen, med application data, plus SQL Server-version og eventuelle stored procedures der hører til. Liste over alle integrationer der ikke lever inde i NAV-koden: EDI, webservices, filudveksling, SQL-links, BI-værktøjer, helst med en kort teknisk beskrivelse af hver snitflade. Til sidst en beskrivelse af driftsmiljøet, eksisterende dokumentation og en oversigt over åbne support-sager og kendte issues.

Hvis I er på Business Central

Overleveringen ser anderledes ud, fordi størstedelen af setup’et lever hos Microsoft. Vi beder om kildekoden til alle custom extensions, helst som Git-repo eller AL-source-eksport, samt source for eventuelle per-tenant apps der ikke er publiceret til AppSource. En oversigt over hvilke AppSource-apps I kører, med versionsnumre. Tenant- og environment-info: production- og sandbox-tenants, brugerantal og licenstyper på Microsoft-siden, custom permission sets. Liste over integrationer der lever uden for BC selv: API-clients med Service Principal app-IDs (ikke secrets), webhooks, Power Automate-flows der rammer BC, og eventuelle Azure Functions eller Logic Apps. Plus oversigt over åbne support-sager og adgang til den dokumentation der måtte findes. Hvis I har en testtenant, beder vi også om adgang til den, så vi kan validere op imod produktion uden at røre live data.

Der er ikke noget i det her der er usædvanligt. Det er listen vi har set hver eneste gang, og den nuværende partner kender den.

Og når den del er på plads, kører vi videre med jer.

Vi kører videre med den løsning I har

Ikke med et genskrevet BC fra bunden. Ikke med en migration der kostede lige så meget som den første implementering. Med den løsning I har, gradvist forbedret, med en plan I kan læse og sige “det dér giver mening”.

Bevares. Nogle gange viser en vurdering at løsningen er så skrøbelig, at det reelt er billigere at starte forfra. Men det er uhyre sjældent.

Vi arbejder ikke bag ryggen på jeres nuværende partner uden jeres udtrykkelige samtykke. Vi ønsker i stedet en god dialog med både jer og jeres gamle partner. Det har vi gjort mange gange før, og alt kan løses i fred og fordragelighed, når bare I har taget beslutningen.