How to Handle Custom Solutions and Workflows During SharePoint Migration

One of the first things clients ask when they start a SharePoint migration project is some version of: “What happens to all our custom stuff?” It is a fair question. Over the years, most organizations build up a real collection of custom workflows, forms, scripts, and solutions that quietly keep operations running. When it is time to migrate, those assets do not always have an obvious home in Microsoft 365 or the Power Platform.

Having worked through this challenge with organizations of all sizes, the answer is rarely simple, but there is always a clear path forward. Here is how Compass365 approaches it.

The “Custom” Problem Is Bigger Than Most Teams Realize

When we do an initial discovery with a new client, we almost always find more custom solutions than anyone expected. Some are well-documented but many are not. We find InfoPath forms that were built years ago by someone who left the company, SharePoint Designer workflows that are deeply embedded in department processes, custom web parts, event receivers, timer jobs, and farm solutions sitting in on-premises environments that nobody wants to touch because they are afraid of breaking something.

The challenge with migration is that these assets do not just move over automatically. Microsoft 365 is a different environment with different capabilities and constraints. What ran fine on-premises may not run at all in the cloud without being rebuilt or replaced.

Start With a Workflow and Customization Audit

Before any migration work begins, we conduct a thorough audit of the existing environment. The goal is to understand what is there, how it is being used, and how business-critical it actually is. Not everything that exists needs to be migrated.

We look at:

  • Workflow volume and usage: Which workflows are actually running? Which have not been triggered in two years?
  • Business impact: Does this process support a core function, or is it a workaround that outlived its purpose?
  • Ownership: Is there someone in the organization who understands this customization, or is it truly undocumented?
  • Migration path: Can this be replicated in Power Automate, rebuilt with Power Apps, or does it need a different approach entirely?

This discovery phase is not glamorous, but it is probably the most important work we do on any migration project. Going in without it is how organizations end up with broken processes on the other side of a migration.

What Happens to Legacy Workflows and Forms

This is the question most clients are really asking when they worry about custom solutions. The honest answer is that some things need to be rebuilt, some need to be modernized, and some should simply be retired.

Rebuild and Modernize

For workflows and forms that are genuinely business-critical, the answer is usually a rebuild on the modern stack. InfoPath forms get replaced with Power Apps. SharePoint Designer workflows get rebuilt in Power Automate. In most cases, the new version is actually better: more reliable, easier to maintain, and with better visibility into what is happening at each step.

When we rebuild, we also use it as an opportunity to simplify. Legacy workflows tend to carry a lot of logic that was added incrementally over the years. Taking a fresh look often surfaces steps that can be consolidated or removed altogether.

Retire What No Longer Serves a Purpose

Not everything should be migrated. Some workflows exist because a process made sense five years ago and nobody turned it off. Part of what we do during discovery is help clients have that conversation with their stakeholders: is this still solving a real problem? If not, migration is a natural opportunity to let it go.

Replace With Out-of-the-Box Functionality

Microsoft 365 ships with a lot of native capability that simply did not exist when many of these custom solutions were built. Sometimes a custom workflow can be replaced entirely by a built-in approval feature, a Teams channel, or a simple Power Automate template. When that is the case, the recommendation is usually to use the native feature rather than recreate the custom logic.

Managing the Transition Without Disrupting Operations

One concern that comes up constantly is timing. Organizations cannot afford to have their processes go dark during a migration. We handle this by running old and new systems in parallel wherever possible, and by sequencing the migration so that high-risk, high-volume workflows are migrated last once the approach has been validated with lower-stakes processes first.

We also make sure end users are not surprised. If a form they use every day is going to look different after the migration, they should know that ahead of time. A few targeted training sessions or user guides can make the difference between a migration that feels smooth and one that generates a wave of support tickets.

The Power Platform Is Usually the Right Landing Zone

For most organizations, the Power Platform becomes the home for modernized workflows and custom solutions after a migration. Power Automate handles workflow automation, Power Apps replaces custom forms and lightweight applications, and Power BI gives teams visibility into the data that used to live in static SharePoint lists.

One of the advantages of landing on the Power Platform is that these solutions are genuinely easier to maintain going forward. Administrators can update flows and apps without developer support. That is a meaningful change for organizations that have been dependent on IT to make changes to their legacy workflows.

Ready to Talk Through Your Migration?

Every migration is different, and the custom solutions piece is usually where the real complexity lives. If you are planning a move to Microsoft 365 and want to understand what your legacy workflows and customizations mean for your timeline and scope, Compass365 can help.

Learn more about our migration and modernization services: Compass365 Microsoft 365 Migration and Modernization

{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Can SharePoint Designer workflows be migrated directly to Microsoft 365?", "acceptedAnswer": { "@type": "Answer", "text": "Not directly. SharePoint Designer workflows are not compatible with SharePoint Online. They need to be rebuilt in Power Automate. The good news is that Power Automate is significantly more capable, so the rebuild usually results in a better workflow than the original." } }, { "@type": "Question", "name": "What happens to InfoPath forms during a SharePoint migration?", "acceptedAnswer": { "@type": "Answer", "text": "InfoPath is retired and not supported in SharePoint Online. Forms need to be rebuilt, typically in Power Apps or using SharePoint native list forms. Each form is assessed during discovery to determine the right replacement approach based on complexity and usage." } }, { "@type": "Question", "name": "How long does it take to migrate custom workflows?", "acceptedAnswer": { "@type": "Answer", "text": "It depends on volume and complexity. A simple workflow can be rebuilt in a day. A complex, multi-stage approval process with conditional logic may take several weeks. The audit phase provides enough information to build an accurate timeline before any migration work begins." } }, { "@type": "Question", "name": "Do we need to migrate everything at once?", "acceptedAnswer": { "@type": "Answer", "text": "No, and a phased approach is generally recommended. Starting with lower-risk workflows lets you validate the migration approach, work out any issues, and build confidence before moving to your most critical processes." } }, { "@type": "Question", "name": "What if our custom solution was built by a vendor and we don't have the source code?", "acceptedAnswer": { "@type": "Answer", "text": "This comes up more than you might expect. In most cases, the functionality can be reverse-engineered by observing the solution's behavior and reviewing the SharePoint environment. From there, it gets rebuilt natively in Microsoft 365. It takes more effort than a straightforward rebuild, but it is very rarely a blocker." } } ] } .c365-faq { max-width: 800px; margin: 0 auto; font-family: inherit; } .c365-faq h2 { font-size: 1.6rem; font-weight: 700; margin-bottom: 1.5rem; color: #1a1a1a; } .c365-faq-item { border-bottom: 1px solid #e5e7eb; } .c365-faq-item:first-of-type { border-top: 1px solid #e5e7eb; } .c365-faq-question { width: 100%; background: none; border: none; text-align: left; padding: 1.1rem 0; cursor: pointer; display: flex; justify-content: space-between; align-items: center; gap: 1rem; font-size: 1rem; font-weight: 600; color: #1a1a1a; font-family: inherit; line-height: 1.4; } .c365-faq-question:hover { color: #0066cc; } .c365-faq-icon { flex-shrink: 0; width: 22px; height: 22px; border-radius: 50%; background: #0066cc; color: #fff; display: flex; align-items: center; justify-content: center; font-size: 1.1rem; font-weight: 400; line-height: 1; transition: transform 0.25s ease; } .c365-faq-item.open .c365-faq-icon { transform: rotate(45deg); } .c365-faq-answer { max-height: 0; overflow: hidden; transition: max-height 0.3s ease, padding 0.3s ease; font-size: 0.97rem; color: #444; line-height: 1.7; } .c365-faq-item.open .c365-faq-answer { max-height: 300px; padding-bottom: 1.1rem; }

Frequently Asked Questions

Not directly. SharePoint Designer workflows are not compatible with SharePoint Online. They need to be rebuilt in Power Automate. The good news is that Power Automate is significantly more capable, so the rebuild usually results in a better workflow than the original.
InfoPath is retired and not supported in SharePoint Online. Forms need to be rebuilt, typically in Power Apps or using SharePoint native list forms. Each form is assessed during discovery to determine the right replacement approach based on complexity and usage.
It depends on volume and complexity. A simple workflow can be rebuilt in a day. A complex, multi-stage approval process with conditional logic may take several weeks. The audit phase provides enough information to build an accurate timeline before any migration work begins.
No, and a phased approach is generally recommended. Starting with lower-risk workflows lets you validate the migration approach, work out any issues, and build confidence before moving to your most critical processes.
This comes up more than you might expect. In most cases, the functionality can be reverse-engineered by observing the solution's behavior and reviewing the SharePoint environment. From there, it gets rebuilt natively in Microsoft 365. It takes more effort than a straightforward rebuild, but it is very rarely a blocker.
document.querySelectorAll('.c365-faq-question').forEach(function(btn) { btn.addEventListener('click', function() { var item = this.closest('.c365-faq-item'); var isOpen = item.classList.contains('open'); document.querySelectorAll('.c365-faq-item.open').forEach(function(el) { el.classList.remove('open'); }); if (!isOpen) item.classList.add('open'); }); });