Moving every version of every file sounds like the safe, conservative choice. In practice it usually isn't, for a few reasons:

Decide version retention policy before migration starts, not during. Business critical libraries, contracts, financial records, board papers, may genuinely warrant full version history because of audit or legal requirements. General working folders, meeting notes, draft decks, day to day project files, usually don't need more than the last handful of versions to be useful.

This decision works best as a short policy statement agreed with stakeholders early, rather than a judgement call made library by library during the technical migration. It gives the migration team a clear rule to apply consistently, and it gives the business a chance to flag any library that genuinely needs an exception before it's too late to add one.

Most tools can, but SharePoint Online's version limits and migration performance mean very long version histories are often trimmed or capped by design rather than by accident.

That depends on the content type. Regulated or contractual documents may need full history, while everyday working files usually don't need more than a handful of recent versions.

Only if it still exists in the source system's backup. Once a migration is complete and the source is decommissioned, unmigrated versions are typically gone for good.

Before you decide what to carry over, run through GTconsult's SharePoint Migration Checklist. It covers content analysis up front and file integrity and version checks once the move is done.

It depends entirely on content volume, permission complexity, and customisations. A small, clean tenant can move in days. A large one with legacy workflows and unique permissions can take months.

Yes, with proper pre-migration content cleanup and a phased cutover. Skipping the audit step to save time almost always costs more time later, once the real complexity surfaces mid-project instead of before it starts.

Undocumented permission structures and legacy customisations that only surface once the migration is already underway, usually because nobody had visibility into them at the scoping stage.

Psychologists Daniel Kahneman and Amos Tversky coined the term "planning fallacy" in 1979 to describe a specific, consistent human tendency: we underestimate the time, cost, and risk of a task, while overestimating its benefits, and we do this even when we have direct personal experience of being wrong about the exact same kind of task before. Kahneman later won the Nobel Prize in economics in part for this body of work.

The classic study illustrating it is almost funny. Psychology students were asked to estimate how long their senior thesis would take. The average guess was under 34 days. Only around 30% of them actually finished within their own predicted timeframe, despite having written papers before and knowing, going in, that they tend to run long. Knowing the pattern didn't stop them from repeating it.

The mechanism researchers point to is what's called the "inside view." When people plan, they focus on the specifics of the project in front of them, the exact steps, the specific team, the particular timeline, rather than on how similar projects have actually gone in the past. That inside view feels more rigorous, because it's detailed and specific to your situation. It's also exactly what produces the underestimate, because it quietly excludes all the ways things went wrong on comparable projects that weren't yours.

The documented fix is called the "outside view," deliberately setting the specifics of your project aside and asking instead: how did this category of project actually go, across everyone who's attempted it. That's a harder habit than it sounds, because the inside view always feels more relevant to your case. It rarely is.

This is what a genuine reference class looks like in practice, rather than an abstract idea. Based on GTconsult's own migration work, rough timelines by environment size: under 50 users and 500GB of data sits at around a couple of weeks. 50 to 300 users, 500GB to 5TB, runs 1 to 3 months. 300 or more users, 5TB or more, runs 3 to 6 months minimum, and that's before accounting for custom functionality, classic web parts, or on-premises workflows that need rebuilding into Power Automate.

None of those numbers come from guessing at your specific project. They come from having run enough migrations to know what actually tends to happen, which is exactly the outside view this whole piece is about.

The planning fallacy doesn't go away because you've heard of it, the psychology students knew they tended to run long and still underestimated. What actually helps is building the outside view into the plan deliberately, asking someone who's run this category of project many times what actually tends to happen, rather than reasoning from your own specific case alone. That's most of what a good delivery partner is actually for: not extra hands, a reference class of every time this has gone wrong before, applied to your project before it does.

The same pattern shows up well beyond SharePoint migrations. It's just as true of a Power Apps build, a Microsoft Fabric implementation, or an agentic AI rollout, teams plan from the specific project in front of them rather than from how similar projects in that category have actually gone. Our Copilot Readiness Checklist is built entirely from that outside view for Copilot and Microsoft 365 adoption specifically, and it's the same discipline we bring to Power Apps, Fabric, and agentic AI builds too.

Planning a migration and want the outside view before you start? Get in touch and we'll tell you what actually tends to happen.

For SharePoint on-premises users, the retirement means Microsoft stops providing support, updates, and security patches. The forms may continue to function, but you’re operating on borrowed time with unsupported software. That creates real risk across three areas:

This is where organisations often get stuck. Not every InfoPath form should be rebuilt the same way. The right replacement depends on what the form does and how complex it is.

For forms that are part of broader business processes and need rich integration with other systems, Power Apps is often the right direction. It’s Microsoft’s official successor to InfoPath, tightly integrated with SharePoint, Teams, and the wider Power Platform. For workflows, Power Automate replaces what SharePoint Designer used to do.

But here’s the honest truth: Power Apps isn’t always the fastest path for straightforward SharePoint list forms. Some forms don’t need the full Power Platform treatment. They need a modern, responsive form that works natively in SharePoint without the overhead of a canvas app build.

This is where it gets practical. One of the biggest headaches with InfoPath migration is the manual effort. Reading form designs, recreating layouts, reconnecting data sources, rebuilding logic. For organisations with dozens or hundreds of forms, that’s months of work.

GTconsult partners with Lightning Tools, whose Form Migrator is purpose-built for exactly this problem. The tool scans your SharePoint environment, detects InfoPath forms, reads the form design including layout, images, repeating tables, and logic, and lets you preview the form before publishing it to a SharePoint list.

From there, you have flexible options. You can migrate to Power Apps for forms that need standalone app capabilities. Or you can migrate to Lightning Forms for SharePoint-native forms with conditional formatting, cross-site lookups, and automation built in. The Form Migrator handles both form design and data migration, preserving field values, attachments, metadata, and relationships.

The entire process runs locally on your workstation. No form data leaves your environment. For security-conscious organisations, that matters.

Lightning Tools also includes an ROI calculator within the tool, so you can see exactly what the migration saves you compared to rebuilding forms from scratch.

Need help with your InfoPath migration?

Chat to GTconsult. Let’s assess your environment and build a plan before the deadline.

Here's something that surprises people who haven't been through a full SharePoint migration: the actual moving of data is often not the hardest part.

Before you migrate a single document, you need to know what you have. That means auditing every site collection, every document library, every custom permission level, every workflow, every Add-In, every integration that touches SharePoint. In environments that have been running for five or ten years, that audit alone can take weeks.

Then comes the conversation about what to bring across, what to rebuild, and what to retire. Classic SharePoint Designer workflows won't survive the migration to SharePoint Online as-is. They need to be rebuilt in Power Automate. Add-Ins built on the retiring framework need to be redesigned using modern solutions. InfoPath forms need to be replaced.

None of that is technically impossible. All of it takes time.

• April 2, 2026: SharePoint Add-Ins and classic SharePoint 2013 workflows retire. Any business process built on these frameworks stops working. This isn't a 'soft' retirement with a grace period — it's a hard cutoff.

Let's talk about what happens when organisations start their migration planning in Q1 2026 instead of now. A few things tend to happen:

A properly planned SharePoint migration isn't just a technical exercise. It has several distinct phases, and each one has genuine business value:

• Environment assessment: Understanding exactly what you have — content, customisations, permissions, integrations, and ROT (redundant, obsolete, and trivial) content that doesn't need to move at all.
• Workflow and Add-In inventory: Cataloguing every automated process and identifying what needs to be rebuilt in modern tools like Power Automate and Power Apps.
• Migration path decision: Choosing between SharePoint Online, SharePoint Subscription Edition, or a hybrid approach based on your compliance requirements and cloud strategy.
• Phased execution: Running pilot migrations, validating, then executing in phases with proper testing at each stage.
• Change management and adoption: Making sure your users understand what's changed, why it changed, and how to work effectively in the new environment.

Start that process now and you have time to do each of those things properly. Start it in January 2026 and you're making hard choices under pressure.

Whether you are a large association, an SME, or a sector body navigating complex stakeholder environments, the challenge with Microsoft 365 is rarely the technology itself. It is adoption; it is knowing which tools to prioritise; it is having a partner who understands your context before prescribing a solution.

That is why our approach to IT support (for the agricultural sector in South Africa and across every industry we serve) starts with listening. We ask the hard questions: Where are the gaps? Which tools are going unused? What is creating friction for your team day-to-day? And what does a realistic, achievable roadmap actually look like for your organisation?

For our A Team clients, this kind of session is part of the package; not an add-on, not a special occasion. It is what a premium, long-term Microsoft 365 support relationship looks like in practice.

Quietly, intentionally, and with a clear plan. No fanfare. Just the work.

Not every organisation has the same needs, and that is exactly the thinking behind our Blue Sky Events. Blue Sky is GTconsult's exclusive, interactive Microsoft 365 workshop format, designed to bring certified M365 specialists directly to your team (on-site or virtually) anywhere in South Africa.

Every Blue Sky session is built around your organisation's specific challenges and goals. There is no generic content, no off-the-shelf slides; just practical, hands-on learning with actionable takeaways your team can implement immediately. Whether that is streamlining collaboration in Teams, unlocking automation through Power Automate, or getting more from tools your team already has access to, we build the session around what actually matters to you.

Blue Sky Events are open to everyone: existing GTconsult clients and organisations simply exploring what better Microsoft 365 support in South Africa could look like for them.

Yes. GTconsult provides Microsoft 365 support and M365 consulting across South Africa, including KwaZulu-Natal, the Western Cape, and beyond, both on-site and virtually.

We work across sectors including agriculture, financial services, insurance, retail, and more. Our M365 consulting approach is tailored to each organisation's context; it is never a one-size-fits-all solution.

No. Blue Sky Events are open to any organisation interested in getting more from their Microsoft 365 environment. Whether you are an existing client or brand new to GTconsult, there is a session for you.

It's a fair question because the phrasing can feel a bit abstract. Here's what it means in plain language:

After July 14, 2026, Microsoft will no longer release security updates for SharePoint Server 2016 or 2019. They won't fix bugs. They won't patch vulnerabilities. If a cyber threat specifically targets your version of SharePoint, Microsoft will not respond. You're on your own.

Your server won't suddenly shut down. Everything will look exactly the same the morning of July 15. Files will still open. Sites will still load. But underneath that familiar interface, you'll be running a platform that no longer has anyone watching its back.

Here's what makes this even more urgent: July isn't the only deadline you need to worry about.

On April 2, 2026, Microsoft is retiring the SharePoint Add-In model and classic SharePoint 2013 workflows- permanently. If your environment relies on workflows built in SharePoint Designer, approval processes tied to the Add-In framework, or third-party add-ins using Azure ACS authentication, those things will stop working before July even arrives.

April 2, 2026. That's less than a year away as you're reading this.

This affects more organisations than you'd think. A lot of business-critical processes, finance approvals, HR routing, records management, procurement sign-offs, were built on classic SharePoint workflows. When these retire, they don't just slow down. They break.

• SharePoint Server Subscription Edition (SE): The on-premises path for organisations with compliance requirements or data sovereignty constraints. Released in 2021, it runs on Microsoft's Modern Lifecycle — no fixed end-of-life date.

• Hybrid approach: Combining on-premises SharePoint SE with SharePoint Online for organisations that need a phased transition or have specific data that must remain local.

If your SharePoint environment went down tomorrow, not a migration, just an unplanned outage after July 2026, how long could your business operate? Who would you call? What would your IT team do without a Microsoft support ticket to open?

That's the risk you're accepting by waiting.

At GTconsult, we've spent 15 years helping organisations navigate SharePoint migrations. We know what a well-planned migration looks like, and we know what a rushed one costs. The difference is almost always time — specifically, how much of it you have left when you start.

Let's talk about what's actually happening in most organisations.

Your team opens Outlook. They jump into a Teams meeting. Maybe someone opens a Word doc or an Excel spreadsheet. And that's... pretty much it.

But your Microsoft 365 licence — whether it's Business Standard, E3, or E5 — includes a lot more than email, meetings, and documents. We're talking SharePoint for document management and intranets, OneDrive for personal cloud storage (up to 1TB per user), Power Automate for workflow automation, Microsoft Forms for surveys and data collection, Planner and To Do for task management, Lists for structured data tracking — and depending on your plan, even more.

Most of these tools are sitting there, fully licenced, fully available, and completely untouched.

Here's where it gets frustrating. Organisations will pay for a Microsoft 365 E3 licence and then also pay separately for Dropbox, Trello, SurveyMonkey, or Zoom — tools that do what their existing licence already covers.

Not because Microsoft 365 can't do it. But because nobody on the team knows it can.

Think about that for a second. You're essentially paying twice for the same capability — once through your M365 licence and again through a third-party subscription — just because your people haven't been shown what's already available.

And it's not their fault. Nobody sat them down and said, "Hey, you know that thing you're using Dropbox for? OneDrive does that. And it's already included in what we're paying for." Or, "That approval process you're running over email? Power Automate can handle that automatically."

Let me give you a few examples of what most teams are missing, even on a standard Business Standard or E3 licence:

It's not about becoming a power user overnight. It's about making sure your people understand the basics properly and then building from there.

It starts with the fundamentals: knowing where to save files (OneDrive for personal, SharePoint for team), understanding how Teams, SharePoint, and OneDrive work together, and being able to share files with a link instead of an attachment.

Then you layer on productivity skills: co-authoring documents in real time, using Planner for project tracking, setting up basic automations, organising SharePoint sites so people can actually find things.

And for the people who want to go further — your site owners, your digital champions, your IT-adjacent team members — there's governance, security settings, and advanced automation with Power Automate and eventually Copilot.

The point is, it's a journey. Not a single event.

Before you do anything else, run a quick mental audit. Ask yourself:

Are we paying for any third-party tools that duplicate what Microsoft 365 already offers? When was the last time our team received structured M365 training? Can our people confidently explain the difference between OneDrive and SharePoint? Does anyone on the team know how to set up a basic Power Automate flow? Are we using SharePoint for document management, or is it just a dumping ground?

If most of those answers make you uncomfortable, that's your sign.

Content Security Policy is a browser-level security standard that controls which scripts a page is allowed to load and execute. It's one of the most effective defenses against cross-site scripting (XSS), clickjacking, and code injection attacks.

Until now, SharePoint Online has been running CSP in report-only mode — logging violations without actually blocking anything. That changes on 1 March when enforcement goes live. After that date, any script that doesn't comply with the CSP rules will be blocked by the browser, potentially breaking custom web parts, third-party tools, and SPFx solutions.

Step 1: Check the Browser Console

Open any SharePoint page that uses custom solutions, press F12 to open Dev Tools, and look for CSP violation messages in the Console tab. You'll see entries like:

• "Loading the script '<url>' violates the following..."
• "Executing inline script violates the following Content Security Policy directive..."

Step 2: Use Microsoft Purview

For a tenant-wide view, go to Microsoft Purview (purview.microsoft.com) and create an audit report filtering for the activity "Violated Content Security Policy." This gives you a comprehensive list of every page and script generating violations across your environment.

Step 3: Review the Directives

Pay attention to both Directive 12 (script-src) and Directive 13 (style-src) violations. Both are relevant — Directive 13 applies to inline code constructs that will also be blocked under enforcement.

Add Trusted Script Sources

Go to SharePoint Admin Center → Advanced → Script sources and add any external domains your solutions depend on. A few things to note:

• You can add up to 300 entries.
• Overly broad wildcards like*or*.domainare not allowed.
• Use targeted wildcards to consolidate where possible.
• If a script loads from a CDN, you need to trust that specific CDN domain.

Refactor Inline Scripts

This is the big one. Any JavaScript embedded directly in HTML, event handlers, or injected viainnerHTMLordocument.write() must be moved into external.jsfiles hosted at a trusted location. There's no shortcut here —unsafe-inlineis not permitted, and Microsoft will not provide nonce values.

Validate Auto-Trusted Sources

If you usecdnBasePathwithout a trailing slash, the auto-generated Trusted Script Sources entry may not match correctly. Double-check these entries manually after deploying your solutions.

This pushes enforcement to June 1, 2026. It's a one-time delay — use it wisely and don't treat it as a permanent fix.

Once enforcement begins, end users may see broken functionality or warning messages on pages that rely on non-compliant scripts. Get ahead of this with proactive communication:

• Explain that this is a security improvement, not a system failure.
• Provide a clear path for users to report issues.
• Coordinate with any third-party vendors whose solutions run in your SharePoint environment.