We hebben onlangs een carve-out gepland: één Atlassian Cloud-omgeving, 4.500 gebruikers, die twee gescheiden omgevingen moest worden.
Het is geen migratie. Een migratie heeft een bron en een bestemming. Een carve-out heeft één bron die er twee moet worden, en het lastige zit nooit in de data.
Drie dingen gaan niet netjes uit elkaar.
1. Mensen die aan beide kanten horen
De organisatie die een e-maildomein verifieert, beheert de accounts op dat domein. Eén domein, één beherende organisatie. Dat gaat goed tot de splitsing mensen oplevert die echt in beide entiteiten moeten werken.
Op dat moment zet je geen instelling om. Je bepaalt bij welke entiteit iemand hoort, en welke entiteit beleid op dat account mag afdwingen. Shared services, groepsfuncties, iedereen die over de lijn heen gedetacheerd is: stuk voor stuk een besluit.
Dat gesprek hoort bij HR en juridische zaken, niet bij Jira-beheerders. Het moet ook vroeg gebeuren, want toegangsontwerp, licentieaantallen en migratievolgorde hangen allemaal af van het antwoord.
2. App-licenties worden duurder, niet goedkoper
Marketplace-apps worden per site gelicentieerd en geprijsd per gebruikersstaffel. Splits 4.500 gebruikers over twee sites en je betaalt niet twee keer de helft. Je betaalt twee staffels, en het totaal komt hoger uit dan wat de huidige omgeving kost.
Dat verrast finance, en het verrast ze laat, meestal nadat het separatiebudget al vaststaat.
Daaronder zit een tweede probleem. Verschillende apps hebben geen ondersteunde manier om een deel van hun data naar een andere site te verplaatsen. Dan is de keuze: configuratie met de hand opnieuw opbouwen aan de nieuwe kant, of de app helemaal achterlaten. Beide kosten geld, en beide vragen om de leverancier aan tafel in plaats van een aanname.
3. Content die beide kanten nodig hebben
In een carve-out bestaat delen niet. Elke Confluence-space en elk Jira-project komt aan één kant van de lijn terecht.
Waar beide kanten iets echt nodig hebben, heb je twee opties. Dupliceren, en accepteren dat de twee kopieën vanaf de dag na cutover uit elkaar gaan lopen. Of een kant kiezen, en de andere laten werken zonder.
Geen van beide is een technisch besluit, al wordt het wel als zodanig bij je neergelegd.
Het patroon eronder
Alle drie hebben dezelfde vorm. Een carve-out legt elk besluit bloot dat een bedrijf stilzwijgend heeft uitgesteld. Wie is hier eigenaar van. Wie betaalt dat. Voor welke entiteit werkt deze persoon eigenlijk.
Die vragen zijn niet nieuw. De splitsing haalt alleen de mogelijkheid weg om ze niet te beantwoorden.
Het Atlassian-werk is de makkelijke helft.
Als dit eraan komt
Staat er een splitsing, fusie of afsplitsing op de rol en zit je Atlassian-omgeving er middenin, begin dan met plannen voordat de juridische einddatum vaststaat. Zodra die datum er is, worden je opties snel smaller en gaan de dure workarounds eruitzien als de enige.