We can refer to a case we encountered at Strator; as part of the replacement of a document management system, we had to handle several million documents in a highly regulated environment. Around 10 per cent of the documentation was to be transferred for active use in the new system. The remainder was to be preserved but not used in day-to-day work, and was therefore placed in an archive. 

The distribution of the workload was striking. Migrating the approximately 10 per cent required around 90 per cent of the workload. Archiving the remaining 90 per cent – approximately three million documents – required the remaining 10 per cent, even though the documents had to be tagged with selected metadata and retention periods and organised into virtual archive boxes as part of the archiving process. 

This did not mean that archiving was taken lightly. The difference stemmed from the fact that documentation intended for active use in a new system must be adapted to a new context. The documents must fit into the system’s structure, metadata must be mapped and, where necessary, enriched, and the result must be checked. Information that is to be retained but is no longer part of day-to-day use can be handled far more simply, as it does not need to be adapted to all the structures and workflows that apply to active documentation. 

This example highlights a key decision in a major migration: not all information necessarily needs to be transferred to the new system. Instead, the organisation should determine what the future of the information should be. Some information should be migrated for continued use, some should be archived, and some may be discarded following a controlled assessment. 

The costly part is making the documentation usable in a new context 

The approximately 10 per cent of the documentation that was to be incorporated into the new system was first selected, and then it had to be prepared for a new way of being used. 

The aim of introducing the new system was to support the automation of parts of a process that had not previously been automated. This required more and more detailed data on the products covered by the documents. Key product information was already available in the organisation’s ERP system. The task was therefore to establish a logical link between the documents and the relevant information and to enrich them during the migration. 

Some of the documentation could be automatically matched with the information from the ERP system. However, the data quality and recording practices in the old document management system meant that the link could not be established automatically for all documents. Some documents therefore required manual preparation before the enrichment could be carried out in a controlled manner during the migration itself. 

In other words, it was not merely a matter of moving or adapting existing metadata from one field to another. The documentation had to be linked to information from another business system and brought up to a standard where it could be incorporated into new, automated workflows. 

The 10 per cent did not constitute a single, uniform set of documents. They consisted of several groups of documents, each with its own characteristics, peculiarities and enrichment requirements. The rules for selection, matching and adaptation therefore had to be defined separately for the different groups. 

This explains why a relatively small proportion of the total volume of documents could account for the bulk of the workload. The documents did not simply have to be transferred. They had to function correctly in the new context and support the purpose for which the new system had been established. 

This is one specific example, but the combination is a familiar one from our work on migrations: the new system must support a new or changed practice; data in the existing material is not necessarily sufficient for the new purpose; and only part of the documentation will continue to be actively used. 

Expert insight with a high ‘hourly rate’ 

In this case, it is worth paying a little attention to the client; Anja, an employee at our client’s organisation, sat down with us and used her in-depth professional insight to help us distinguish between the documentation that should continue to be used actively and that which should simply be retained. 

Just think how much her time saved the organisation in consultancy fees to us. The organisation avoided spending resources on adapting, enriching, migrating and checking documents that were not to be used in the new system. Her actual ‘hourly rate’ on the project was therefore quite high. 

A technical analysis can show which documents exist, how large they are, and what metadata they contain. We external specialists can act on the basis of the insight and understanding we can provide. However, a deep business understanding of what the documents are used for, what documentary value they hold, and whether they should continue to form part of active processes must come from skilled people with professional insight into the material. 

In this case, that insight had a very tangible financial value. At the same time, it made it possible to focus the bulk of our efforts on precisely the documentation that needed to work well in the new system. 

Everything must be handled – but not in the same way 

In this specific case, there were two destinations for the documentation. The part that was to continue to be used actively was migrated to the new system. The rest was archived. In this particular example, there were no parts of the material that needed to be disposed of. 

In other contexts, controlled disposal may be a third option. This does not alter the fundamental principle: the entire volume of information must be managed, but it does not need to be managed in the same way. 

Documentation that is to continue to be used actively must function within the new system’s structure and work processes. It must be locatable, comprehensible and usable, and it must contain the data required by the new processes. Therefore, migration may involve selection, cleansing, transformation and enrichment. 

Documentation that is to be retained but not used in day-to-day operations serves a different purpose. It must still be retrievable and comprehensible, and it must be stored in accordance with the rules that apply to it. However, it does not need to be adapted to all the functions and workflows that apply in the active system, so this is usually less labour-intensive. 

Information that has neither continued practical value nor needs to be retained as documentation may be disposed of following a controlled assessment. This still requires a decision and a documented process. However, it does not require the information to be prepared for a new system first. 

The classification is therefore not a choice between taking the information with you or letting it go its own way. It is a way of ensuring that each part of the information set receives the treatment appropriate to its future function. 

A smaller volume can be processed more effectively 

If all those several million documents had been processed with the same level of rigour as the active documentation, the scale of the task would have been entirely different. Within a fixed budget and timeframe, the alternative might have been to reduce the quality of the processing in order to get through the entire volume. 

By first distinguishing between the documentation intended for active use and that intended solely for preservation, resources could be concentrated on the active part. Here, thorough work could be carried out on selection, data quality, enrichment and verification, so that the documentation could actually support the new workflows. 

The separation based on future function therefore did not merely reduce the scope of the migration. It made it realistic to process the most important documentation to a high standard and thus derive greater value from the new system. 

The separation can also create some space before go-live 

In fact, the separation also provided a little more flexibility in the project’s timetable. 

Projects can be under considerable time pressure in the run-up to go-live, and this was certainly the case here. Because the volume of information had been separated, efforts could be concentrated on the documentation that needed to be ready for active use in the new system from day one. 

Archiving and, where necessary, the controlled disposal of the remaining information can, in many cases – as here – be carried out at a later stage as part of the planned phasing out of the old system. This allows the remaining volume of information to be dealt with at a leisurely pace, without it putting a strain on the most critical part of the project’s schedule. 

However, ‘subsequently’ must not come to mean ‘indefinitely’ or ‘never’. The phasing out must be planned, and there must be accountability, resources and a clear end to the work. Otherwise, the old system may end up as a ghost that continues to be operated and incurs costs, even after the new system has been put into use. 

The right outcome is not necessarily to migrate as much as possible 

A successful migration does not, therefore, necessarily mean that as much of the old system’s content as possible has been transferred to the new one. 

A successful outcome is when the information that is to be used going forward works effectively in its new context. Historical documentation that needs to be retained is archived securely. And information for which there is no longer a basis for retention is dealt with through a controlled decision-making process. 

This requires the organisation to review the information prior to migration and decide on its future. This professional assessment takes time, but the case also demonstrates just how much time it can save – and how significant an impact it can have on the quality of the new system. 

So does everything really need to be transferred to the new system? No. But everything must have a controlled future. 

Vibeke Bugge Kristiansen
CEO

The post Do All Documents Really Need To Be Transferred to the New System?  appeared first on Strator.

Here’s what you should do before November 3. 

What did memberOf actually do? 

The preview let a dynamic group rule pull in the members of other groups: 

user.memberOf -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>']) 

It was the closest thing Entra ID had to nested groups that downstream services could read. Organisations used it to flatten a group hierarchy into something SharePoint, Teams, Conditional Access and group-based licensing could consume, because nesting has never worked cleanly for those consumers. 

Microsoft's stated reason for pulling it is scale. During the preview, memberOf was observed to slow dynamic membership processing across an entire tenant, not just for the groups using it. The alternative might be in development, but nothing is releasing yet. 

What will break, and where will you feel it first? 

Frozen membership propagates into everything downstream of the group: 

• SharePoint and Teams access. Leavers keep site and channel access. Joiners never get it. 

• Conditional Access targeting. New employees fall outside a policy scope they should be inside. Your MFA or device compliance policy silently stops covering people. 

• Group-based licensing. New starters go unlicensed. Departures keep consuming licences you pay for. 

• Access packages. Auto-assignment policies stop assigning and stop removing, so a time-bounded grant quietly becomes permanent. 

• Dynamic administrative units. Delegated admin scope drifts away from the org chart. 

For regulated organisations there is a second-order problem. If your access control procedure says membership is maintained automatically by an attribute-driven rule, and that rule has silently stopped evaluating, your documented process and your actual system state have diverged. That is an audit finding, and it is hard to bound afterwards. You have to prove who had access to what, and for how long. 

Which parts of the tenant do people forget to check? 

Almost everyone checks dynamic groups. Two other surfaces carry memberOf rules and almost nobody checks them: 

• Dynamic administrative units. Configured once by someone on the identity team, never touched again, and invisible during a normal access review. When one freezes, delegated admin scope stops tracking the org chart. 

• Entitlement management auto-assignment policies. The rule lives inside the policy's allowed-targets configuration rather than on a group object, so a group-focused export misses it entirely. 
  Both need Microsoft Graph to enumerate properly. Neither shows up if you search only the Groups blade in the admin center. 

The detail almost everyone misses: some of your memberships are already frozen 

Here is the finding that changes how you prioritise, and it comes straight from the preview's documented limitations. 

• memberOf never removed members when a source group was deleted, or when a member was removed from a source group. The documentation states it plainly: affected users remain members of the memberOf group until the rule is modified. 

Read that against the retirement notice. It means the 3 November freeze is not the start of your drift. If any source group referenced in one of your rules has been deleted, or has had members removed, some of your access is already stale today, and has been for as long as that source group has been gone. 
This is why a memberOf discovery exercise should resolve every source group ID in every rule and check whether it still exists. An unresolvable source group ID is not a data-quality annoyance, but a marker for access that stopped tracking reality some time in the past. That is exactly the kind of thing you would rather find yourself, than have found for you during an audit. 

How do you decide what to do with each rule? 

There are three honest outcomes, and a fourth that people avoid naming. 

Rewrite with supported operators. If the source groups correspond to a real attribute, such as department, job title, company name or an extension attribute, express the rule against that attribute directly. That could be considered the best outcome, and it usually forces an overdue conversation about HR data quality. 
Convert to assigned membership. Freeze the membership deliberately and manage it through your joiner/mover/leaver process. It is boring, auditable, and honest about who owns the list. 
Delete the rule. A meaningful share of preview-era groups turn out to serve nothing. 
Accept that some groups need a live union. This is the one people skip.This is the one people skip. If a group's membership only consists of all members in other groups, there is no attribute that expresses that. If it has to stay current, then assigned membership is not a migration.

How do you test a rewrite before you apply it? 

You want both your coverage and precision to be at 100%, but most migration plans only track coverage. 
Coverage is the share of current members the proposed rule still includes. Coverage below 100% means people lose access at cutover. You will hear about it the same morning. 
Precision is the share of the proposed rule's population that is a current member. Precision below 100% means people gain access at cutover. Nobody reports that, which is exactly why it is the dangerous one. 

A rule at 100% coverage and 80% precision looks like a clean migration on the day and is a silent over-grant forever after. When we built our own assessment tooling, we made precision the blocking threshold rather than coverage: the tool will not propose a rewrite that widens access, but it will happily propose one that leaves you a named list of eight people to add back by hand. A short manual task beats an invisible permission expansion. 

Whichever way you compute it, validate the candidate rule in the Entra portal before applying it, and compare membership before and after. 

A 3-step approach 

Step 1: find every use. Export dynamic groups and search the rules for memberOf. Do the same for dynamic administrative units and entitlement management auto-assignment policies via Graph. For each hit, record what consumes it: sites, teams, Conditional Access policies, licence assignments, access packages. The migration risk lives in the consumers, not the group object. If you need certainty and help, get in touch for a free assessment. 
Step 2: decide per group. Note the constraint that pushed people to memberOf in the first place: it could never be combined with other rules or operators. So a rewrite is rarely a like-for-like translation. It is a chance to express the intent properly. 
Step 3: validate and document. Compare membership before and after, confirm the downstream consumers still resolve, record the change. Under GxP, NIS2 or DORA the validation evidence is the deliverable. Leave buffer before 3 November. You do not want the last group migrated on the last day. 

Working with memberOf groups in a regulated environment?

We run a read-only assessment of your tenant and hand you the register, the per-group recommendation and the validation plan. Get In touch

Ulrich Bojko
Head of Development

The post The Entra MemberOf Retirement: Your Groups Won’t Break, They’ll Freeze  appeared first on Strator.

I studied computer science, which is like a Swiss Knife in the IT-sector. During my studies, I learned the basics of almost everything IT, from coding to architecture to analysis. I decided to go to the job market with this solid all-round basis. I started at the Strator as a mix between a business-consultant, an analytic-consultant, and a technical-consultant. With time, I drifted over to the technical side.

I get mostly technical assignments now, which I’m happy about! My first long term project was a large data migration in which we had to extract the metadata and adapt it to the organisation-switch the client was going under. We had to reorganise and rename documents, execute the migration, and deliver an end-to-end report to ensure everything went as planned.

I really enjoyed getting to know the company we were working with. Typically, we investigate the data, the structure it has, the current state of things, etc. We’re trying to figure out what the company needs, and the reasoning. We get to do a bunch of nerdy analysis around data, and combine it with business development to get a lay of the land. Then, there is the technical aspect where you make flows, applications or software. It’s a lot of fun because you get to be technical and nerdy.

After about a year, the project was completed, and it was time for something new. Ulrich decided to take me under his wing, and taught me all about SharePoint. I spent almost all of 2025 learning all there is to know about SharePoint from a senior in the field. It gave me new skills and tools to use as a technical consultant

It’s nice to hear you were taught so much by your colleague. Is there a lot of support between colleagues?

On the rare occasions when we have a slow day, we always find something else to do by helping coworkers. It’s how we go about doing work pro-actively. Aside from that, I think we’re also good at taking care of everybody’s needs and differences. We’re good at embracing people and accommodating them. If anyone is ever a little low on work, we have no issue asking them to help with things either. It’s just how we do things.

This way we also get a pretty clear view of the strengths of the different people working here. It makes us able to really utilise their skills to the fullest, which in turn increases the number of services Strator can provide to a client. Dinah is a good example of this. She possesses a specific skill set and knowledge on how to classify data and files, and she does so with a specific kind of insight she gets from her background. That lead to the creation of the Strategic Information Management – Lite as a part of our Summer Clean-Up campaign. Especially right now, people could really use Dinah’s specific skill set. Making sure your data-landscape is clean and in order is getting more important by the day.

Do you experience those issues with unkept data landscapes a lot in the field?

It is one of those reoccurring issues we come across in the field. We often take on data migration projects in which the project manager, obviously, wants to be most efficient with the time allocated to the project. However, often times we see clients wanting to save time with a migration by forgoing an initial clean-up. We come into the project and are tasked with transferring large amounts of data from A to B, but we can’t complete our initial analysis as it should be, because the data isn’t structured, it’s not classified, or classified in an inconsistent way. The time constraint leads the clients to ask us to proceed with the migration anyway, but then we lose more time on the other side of the migration instead.

After the migration, we need to make sure all the data has been transferred properly, but if the original batch of data is in complete disarray, it takes way more time to cross reference everything. Aside from time, it also uses up way more of your data allowance to not clean up your data beforehand. When we do a clean-up we look for old, unused, empty and/or corrupted files which take up unnecessary space. Migrating them is completely pointless, and even unbeneficial for the client. Once migrated, the data might look nice because it is in a new UI, but it is still that same mess. Classifying your data would actually enable you to gain efficiency, and allow you to use new technologies to further develop your workflow.

On our end, Having a clean starting point makes it easier to reassure the client that all the work has actually been done correctly. If we are able to show the client one-to-one that the migration has been completed with an optimal structure, there is actual proof that everything is in order, compliant, and that nothing was lost. Carrying out an unstructured migration isn’t impossible, It just requires more resources because everything is less streamlined. Nine times out of ten, forgoing a clean-up of your old structure to try and save time, costs you more time and money in the end.

My advice for any reader would be: clean up your data before getting into a migration, and keep it clean after the migration as well. Do it yourself, have us do it, or someone else, because your data fills up quickly, and having a clean data landscape saves you a lot of time and money in the grand scheme of things, even outside of a migration.

Lastly, is there anything you’re looking forward to at Strator?

I’m looking forward to gaining more experience as a part of the sales team at Strator. I’m very excited to help the company reach greater heights and expand to work on bigger projects on larger scales. I would love to eventually help Strator expand and get bigger projects from big clients.

The post Strator’s Swiss Knife: Meet Christian – Sales and IT Consultant appeared first on Strator.

 The shift is that lifecycle, permissions and classification are becoming the conditions of entry for artificial intelligence, rather than optional refinements to be addressed later. For any organisation planning a Microsoft 365 Copilot rollout in the second half of the year, the changes below are not background detail. They are the new ground rules, and they all point in the same direction.

Grounding Copilot in Trusted Sources 

The most visible of the new capabilities is Authoritative Sites. It allows an administrator to designate specific SharePoint sites as trusted, so that Microsoft 365 Copilot prioritises their content when it answers questions in Copilot Chat and Copilot Search. The setting is applied per site, it requires a Copilot licence, and it is disabled by default. 

The intent is sound. In a large tenant, Copilot must ground its answers in something, and not all content deserves equal weight. The policy published last week and the abandoned draft from several years ago should not carry the same authority, and Authoritative Sites lets an organisation favour the sources that have earned trust. 

What the capability does not do is establish trust on your behalf. Marking a site as authoritative is only beneficial if the site is genuinely current, accurate and well managed. Directing Copilot towards a site filled with stale, duplicated or mislabelled material will, predictably, result in an assistant lacking in reliable information. It is an assistant that repeats your worst content with new confidence, now carrying your own stamp of authority. The feature assumes the organisation already knows which of its sites are trustworthy, but most organisations do not. That assumption is the common thread that runs through the other updates as well. 

External Sharing Becomes Governed by Default 

For years, sharing content with someone outside the organisation would rely on a one-time passcode sent by email. That mechanism is being retired. From July 2026, SharePoint's one-time passcode authentication begins to wind down, and external sharing transitions fully to Microsoft Entra B2B, with completion expected by the end of August. New external invitations already moved to this model earlier in the year. 

In practice, every external recipient now becomes a managed Entra B2B guest rather than the holder of a temporary code. This is a clear improvement in governance, because external access thus falls under the same controls as everything else: Conditional Access, identity protection and centralised guest management. It is also a deadline. External users who relied on the old method can lose access to previously shared content, and the administrative toggle that once governed this behaviour is being removed. 

The implication is straightforward. The guest estate that many organisations have never formally reviewed is about to become a governed surface, whether they are prepared for it or not. Reviewing who has external access, before the transition completes, is time well spent. 

Classification Becomes a Boundary, not a Suggestion 

Permissions describe what a user is allowed to open. They have never, on their own, described what an AI system should refrain from touching. That distinction is now being drawn. 

Through Microsoft Purview, sensitivity labels can exclude content from Copilot grounding, with enforcement rolling out to completion by the end of July. A document classified at a restricted level can be kept beyond Copilot's reach even for users who hold permission to open it directly. Classification stops being advisory metadata and becomes an enforceable boundary, preventing Copilot from gaining access simply because "the user had access", as was the inadequate justification prior to the update.   

For regulated industries this is not a convenience; it is the difference between a Copilot deployment that can be defended and one that surfaces controlled information into a generated answer because the permissions happened to allow it. As with Authoritative Sites, the protection only functions where the labels already exist. A boundary is held only where someone has formed it. 

Governance Becomes a Discipline You Can See 

The quieter theme across these changes is that governance itself is being treated as an operational discipline rather than an annual cleanup. Microsoft is consolidating the activity around site reviews, inactivity, ownership, and attestation into clearer surfaces for the people responsible, and it is improving the reporting that lets administrators locate oversharing and permission risk, so you no longer have to guess. 

Governance is acquiring its own instrumentation, which means it can be measured, assigned and acted upon as ongoing work. 

The Common Premise: Governance Is the Price of Admission 

Step back from the individual features, and the shared premise of these updates is impossible to overlook. Each new capability reads information that is expected to already exist on the site, and acts upon it. Authoritative Sites depend on knowing which sites merit trust. Purview's protection relies on labels having been assigned. Ownership and attestation reviews depend on there being a valid owner to contact. None of these controls create the underlying information; they all consume it. 

Which raises the question: where does that information come from? 

The Half of the Lifecycle Nobody Governs 

Microsoft governs the middle of a site's life and its end. Inactivity detection, ownership reviews, attestation and archiving are all steady-state and end-of-life controls. They assume that a site already exists, already has an owner, already carries a classification and a sensible permission model. They operate on metadata that someone, at some earlier point, was expected to put in place. 

Almost nothing governs the beginning, and the beginning is where the outcome is decided. A site created without a clear owner leaves the attestation policy with no one to notify. A site created without a sensitivity label gives the Purview boundary nothing to enforce. A site created with broad, inherited permissions becomes exactly what the oversharing report will report on later down the line. The costly remediation that fills most governance programs is, almost entirely, the accumulated price of sites that were never established correctly in the first place. This is the gap that experts at Strator are trained to close.

Microsoft's tools are only ever as reliable as the information already recorded on the site. The work of ensuring that information exists from the first moment, and of repairing it where it is missing, is a separate discipline from the controls that later depend on it. 

Two Halves of the Same Lifecycle 

Strator's approach and Microsoft's native lifecycle management are not alternatives to one another. They govern different halves of the same lifecycle, and the provisioning half is the precondition for the steady-state half to function. 

The relationship is direct at every point. Authoritative Sites becomes trustworthy when sites are already classified by tier, because that classification is the natural shortlist of sources that have earned Copilot priority. Purview's classification boundary becomes legitimate when labels are applied at creation rather than retrofitted under pressure. Ownership and attestation reviews become meaningful when valid owners exist from the outset, leaving no orphaned sites for the review to stall on. And oversharing reports have less to find when sites are provisioned with least-privilege access by default. In each case, the native control inherits a foundation it did not have to build. 

Where a Copilot Rollout Actually Begins 

The lesson of this summer's changes is that a Copilot rollout does not begin with a licence. It begins in the content estate beneath it, in the unglamorous discipline of ownership, lifecycle and classification on which every one of these new features quietly depends. The organisations that will adopt Copilot with confidence are the ones that did this work first, and treated it as a foundation rather than a cleanup. 

Microsoft governs the middle and the end of a site's life. Strator governs the beginning. And the beginning is what decides whether everything that follows can be trusted. 

The post Govern First, Then Turn On the AI appeared first on Strator.

In this new series of Blogposts, we will introduce the people that make Strator what it is. With this first interview, we will be introducing Ulrich Bojko, our Head of Development, by asking him about his experiences at Strator. He shares insights on the importance of experts, reliance on AI, and digital sovereignty.

Since 2025, Ulrich has become a core part of Strator. Despite this relatively young cooperation, Ulrich has proven himself to be a valuable part of the team as a man of many ideas with a rigorous work-ethic and a lot of funny jokes. As a SharePoint expert and a business development enthusiast, Ulrich helps Strator reach a little further every day by developing new tools, carrying out massive migrations, and coming up with new ways in which Strator can help companies turn their information into a competitive advantage.

How did you get started at Strator?

My career at Strator started as an external consultant. I am a SharePoint expert and had been working with SharePoint Online and on-premises since 2008. I usually tell people that I can pretty much make SharePoint do anything that they want it to. I’ve made a ton of different solutions, from contract management and QMS systems to extranets and customer portals. Some of them were completely custom-coded, but more recently they have been based on SharePoint functionalities.

Either way, I started as an external consultant for Strator because clients asked them, “Well, now you have moved all of our data into SharePoint, so can you help us do other things with this SharePoint platform?” Of course, this is a completely different speciality, which is where I came in, and I fell in love with Strator and the people there.

When I first saw Strator, it struck me as probably the most boring company I’d ever been invited to. I mean, these librarian geeks talking about classification models and V-models and validation, and all these insane abbreviations like EQ, IQ, PQ, OQ, and whatnot. I thought, “How do you not just die a little inside every day from working with this? This is like a whole new level of geekiness.”

But once I really dug into it, I realised it wasn’t that boring. The moment you need to move 3 or 4 million files without losing any of them, while having it all under control and being able to prove that you did everything correctly, it starts becoming fun. I’m not only building technical solutions, but I’m also getting my hands dirty in the piles of data.

You’re currently the Head of Development. What does that mean?

I’ve always been fond of business development, even though I was a freelancer for 10–12 years. If I saw an opportunity, an issue, or a requirement at a company that I couldn’t solve, I always liked being the one with the network to do something about it. I also love talking to a lot of companies, not just clients.

When it comes to business development, I love developing ideas into real products or real offerings that a company can deliver, given the capabilities of the team. I just like seeing how we can package it, do sales, and build a network of clients, vendors, and partners. It’s about 50% of what I do, while the other 50% is solving clients’ SharePoint issues or building things for SharePoint.

I also follow European policy and politics quite a bit as part of the business development side of things. I like seeing opportunities in politics and pinpointing them for our business or our clients.

A lot of politicians are talking about digital sovereignty at the moment, for example, and it is something I have been talking about for the past 20 years. Now, with the shifts in the political climate around the US, the need for digital sovereignty is finally showing up on people’s radars. Every conversation between a vendor and a public-sector institution, municipality, ministry, government, or whatever will have digital sovereignty as number one on the agenda.

Good thing I love advising clients on how to achieve digital sovereignty: not by purchasing a licence, but by adapting certain capabilities. Especially when there are so many misconceptions about digital sovereignty caused by so-called “sovereignty washing,” where companies market their product as the magical button to becoming sovereign. People like swiping a card and believing they are digitally sovereign after five minutes. But suddenly, your new sovereignty-solution reaches a certain limit, requiring you to buy an upgrade, or the price just goes up. Before you know it, you’re stuck with a vendor lock-in and are no longer digitally sovereign. This can happen with both open-source solutions and, let’s say, a Microsoft solution. Making sure people see that is also what I want to do by building a network.

You really seem to enjoy guiding and advising as a part of business development.

I really like having that advisory role. These days, that comes with its own difficulties, though, as AI is often used as some kind of advisor. It’s quite risky because it’s very persuasive in guiding everybody towards the same one-stop-shop solution, since the big models are based on American thinking. You could get a European AI, but either way it is going to be based on some kind of model which will guide its answer. If people want actual knowledge, based on years of experience, they still need a person giving them personalised advice. I love doing that because advice is never a one-size-fits-all situation. I love getting familiar with a company and understanding its processes. All that business development, for Strator or for a client, is something I really enjoy. It allows me to use my technical knowledge and my communication skills. Operating between the tech and the boardroom is really where I’m most at home.

Is this over-reliance on AI something you encounter often?

That and the reliance on licensing to get everything in order instead of relying on actual capability or certain structures. AI is an extremely powerful tool, but it is just a tool. It doesn't work without the proper preparations.

People don’t want to focus on the boring parts, like getting their data in order first. That lack of a solid foundation is why you see statistics showing that somewhere between 70 and 95% of AI implementations or AI projects do not actually deliver the value they were expected to. People have stopped relying on specialists and experts because of all the marketing fluff, and because they don’t have time to go deeper. Besides that, AI will always answer in the way it thinks the prompter wants to be answered, which is why it cannot have the same value as an expert.

That is also some advice I would give to readers: think slow. AI is also a bubble, and it is important to know that it can pop. Companies can go bankrupt and AI services can increase in price drastically overnight. If you’re using AI without thinking about it too much, you might eventually start using AI instead of thinking. What do you do when the bubble bursts?

Be very, very careful when replacing people with AI. It is a handy tool that doesn’t have any critical sense, it doesn’t look beyond the parameters you give it, and it might not be as certain as you think it is. It can be the biggest digital sovereignty threat you can have because, suddenly, if it stops working or gives you wrong answers while your business depends on it, what do you do?

In short: think slow, build a workflow instead of only relying on AI, and hang on to those very valuable human values and capabilities in your team during this AI age.

Lastly, is there a project in the (near) future you are looking forward to?

Well, we've been developing these small tools for clients made to increase their digital sovereignty by helping them govern their SharePoint websites. I've been calling them our "Blueprints", and I am very excited to see them come to life. I've been working on a scan we will be using for our Strategic Information Assessment - Lite, and I will soon talk more about something I've been calling "Site Lifecycle Governance" as a part of these Blueprints. We are still working on the Blueprints, but we will release more news about them as time goes on.

The post Operating Between the Tech and the Boardroom: Meet Ulrich Bojko – Head of Development appeared first on Strator.

This distinction matters more now than ever before, because the strategic stakes are real and the marketing around them is loud. Two recent and substantial pieces of work help cut through the noise: the Danish Agency for Digital Government's December 2025 report on open source in the public sector, and an international survey of sixteen digitally mature countries it commissioned the year before. Read together, they point to the same uncomfortable but useful conclusion. Digital sovereignty is a capability, and capabilities have to be built.

Sovereignty Is Not a Product You Can Buy 

It is tempting to believe that a particular kind of platform settles the question. It does not. You can be genuinely independent on a proprietary stack if you are well governed, and completely trapped on open source if you are not. The brand on the box decides very little. The organisation around it decides almost everything.

The major providers themselves demonstrate the point. Over the past year Microsoft has completed its EU Data Boundary, and introduced sovereign options such as customer-held encryption keys, Europe-based access controls and on-premises deployment of core workloads, all aimed squarely at sovereignty concerns. These are serious investments, and they make sovereignty achievable on a hyperscale commercial cloud in a way that was not possible a few years ago. At the same time, residual questions remain, such as the reach of foreign legislation over data physically stored in Europe, which no purchasing decision fully removes on its own. The lesson is not that one provider is safe and another is not. The lesson is that whatever you choose, the responsibility to understand what you hold, where it sits, and how you would abandon it if needed, does not transfer to the vendor. It stays with you.

So, the real question is never "which platform makes us digitally sovereign." It is "do we understand our configuration, own our data, know our contracts, and have a funded way to change course." Those are organisational properties, not product ones.

Control and Responsibility Are the Same Decision 

The Danish 2025 report is blunt about the trade nobody likes to name. When you take more control of your technology, you also take on more responsibility: licence terms, security updates, support, maintenance, and simply knowing what you are running. Control is not a prize you collect. It is a workload you accept. The report is careful never to claim that more openness is always better; it says the opposite. Make choices based on the value they bring, and be honest about whether you can carry out what you have chosen.

Denmark built a dedicated Open Source Office for its health sector. Although, it was technically well regarded, it withered anyway. Not because of the quality of the code, but because of a lack of organisational and financial backing. Technical excellence does not provide the capability to sustain operational backing. Funding, ownership and leadership do. Especially leadership. The same pattern appears in reverse wherever sovereignty succeeds. It is sustained by an organisation with leadership that decided to allocate resources to it, not by a licence that happened to permit it.

This is why the smallest organisations struggle the most, and why the answer is rarely a heroic in-house rebuild. Acquiring a capability is demanding precisely because it is real work, and pretending a platform removes that work is how dependence quietly accumulates.

The Preconditions Are Where Sovereignty Is Actually Built 

If digital sovereignty is a capability, the practical question becomes what that capability is made of. The Danish report, drawing on the experience of public authorities at home and abroad, sets out a clear and, helpfully, vendor-neutral list of preconditions. These preconditions apply just as much to proprietary software as to open source.

The first precondition is organisation and leadership. Someone has to back the decision, articulate why it is being made, and invest in the competence to carry it, whether that competence is built internally or bought in. The second is a deliberate decision about support and maintenance. It is needed whether the software is open source or not. All software needs support and maintenance, and leaving it unowned would be a mistake. The third is the ability to assess security and maturity, to judge whether there is an active community or a competent supplier behind a component, rather than assuming a license fee guarantees it. The fourth is genuine command of licences, contracts and data, knowing what terms bind you, where your information lives, and what your agreements actually say. The fifth is open standards and integration building, so that systems can talk to one another and, crucially, so that you could change a supplier later without dismantling everything. The last is honest lifetime economics, comparing the full cost of a solution over its life rather than its sticker price, because the value of being able to move never appears on an invoice.

None of these are technical tricks. Every one of them is a discipline. Together, they are what digital sovereignty actually consists of, and the encouraging part is that they can be deliberately developed.

No Organisation Stands Alone 

Organisations do not have to acquire the capability to posses digital sovereignty by themselves, and the most mature countries have understood this. The recurring pattern in the international survey is the rise of shared stewardship: neutral organisations that posses this capability on behalf of many. In Denmark, the OS2 community lets municipalities pool funding and competence around shared solutions, on the principle that those who rely on something help sustain it and keep the ability to change suppliers. Estonia and Finland went as far as founding a joint institution, with staff and a budget, simply to steward software they share. Italy has built a state office to guide and support adoption of open source, Germany has established both a public body to develop shared solutions and an agency to fund the maintenance of critical open source, and the European Union is assembling common building blocks several countries can draw on.

What matters is not which model wins, but that every one of them treats capability as something to be funded, staffed and shared, rather than assumed. Digital sovereignty, at scale, is a collective discipline as much as an individual one.

Digital Sovereignty Is a Leadership Posture 

Leadership, specifically the CIO and/or CTO, are the ones who need to make decisions on digital sovereignty. It is important they do so, during the procurement process itself. Data location, exit-readiness, open standards and clarity over contracts should not be afterthoughts raised once a platform is already chosen. They belong to the requirements, as standard, applied to every vendor regardless of who they are. Treated that way, digital sovereignty becomes the decision to take responsibility for your own infrastructure, to know what you run and why, and to keep your options open on purpose.

The most durable examples are governed, not improvised. Aarhus, for instance, did not become more digitally independent through a single product switch. It set a direction over many years, from a requirement to consider alternatives, to an action plan, to a digital strategy, to budgeted money set aside to widen its choice of suppliers. The throughline is not a technology. It is sustained, value-driven governance, and a refusal to let someone else set the cadence by default. The longstanding principle behind it is worth remembering: choose the best and most economical option regardless of software type.  These options need to be chosen by an organisation that understands what it is choosing.

That capability is what we build at Strator. The platform is yours either way, commercial or open, cloud or on-premises. The real question is whether you can steer it, and whether you could leave it if you ever had to. Digital sovereignty is not simply a phrase on the contract; it is the knowledge that the organisation knows its situation and has the ability to migrate if it chose so.

The post Digital Sovereignty Is Not a Licence. It Is a Capability. appeared first on Strator.

Planning Beats Luck, Prepare For Your Summer Clean-Up

As Summer draws near, many companies will see their office spaces drain, while coworkers go on vacation. That makes Summer the perfect time to clean up your digital working environment without worrying about disturbing the usual workflow within your SharePoint or FileShare sites. However, it is best not to do such a clean-up without the proper preparations. That is why Strator decided to launch a special service package made to do just that.

 

With a Strategic Information Assessment Lite, you can take an easy first step towards improving your data quality and classification in a fast and effective way. Classifying data brings confidentiality, integrity and availability while functioning as a solid basis to support information structure of your organisation, but cannot be done efficiently without an assessment of the current situation at hand.

Read more about Strategic Information Assessments

What You Will Get Out of the Strategic Information Assessment Lite

• A data map overview
• An overall assessment of your data quality
• The current state of compliance of your documents
• A first recommendation of a classification system for your data organisation
• Options for reducing data waste

Coverage

• Platform: FileShare and SharePoint sites
• Scope: Documentation from up to 5 process areas (HR, Finance etc) and up to 1 mio files
• Your involvement: 1 start-up meeting, 1 decision meeting, 1 conclusion meeting

 

Price: 50.000 DKK

Contact us to learn more, without any obligations

Contact Us

The post Get Ready For Your Summer Clean-Up appeared first on Strator.

Document migration is not simply a matter of moving information from one system to another. Migration must also ensure that documents, metadata, and relationships retain their integrity throughout the entire process. 

If a migration is not planned and executed systematically, it may result in a loss of documents, loss of metadata, or loss of document integrity, and therefore evidential value. In regulated environments, this may have compliance implications. In other organisations, it may result in the loss of business-critical information or reduced confidence in the reliability of the migrated data. 

For these reasons, Strator follows a documented migration methodology designed to ensure quality and control throughout the migration process, thereby preserving the integrity and value of your organisation's information.

The post Strator’s Document Migration Methodology: GxP-Ready appeared first on Strator.

The post Strator’s Expertise in SMART Migration appeared first on Strator.

The post What is Digital Sovereignty – When We Talk About Documents? appeared first on Strator.