How to move line of business applications to the cloud

Short answer: Every line-of-business application has three viable paths to cloud – replace it with a SaaS equivalent, host the existing app on cloud infrastructure, or keep it on-prem and connect it to your cloud environment. The right path is per-application, not per-project, and most small businesses end up using all three for different apps. The hard part is not the migration itself. It is the evaluation: figuring out whether the SaaS version of your LOB app is actually mature enough, whether the vendor will support cloud hosting, what your data migration path looks like, and what you do when the vendor flatly refuses to cooperate.

Line-of-business applications are usually the last things to move to cloud, and they are the projects most likely to go sideways. This article covers what counts as an LOB app, the three migration paths in detail, how to evaluate a SaaS replacement honestly, what data migration actually involves, how to manage the vendor relationship during migration, and the specific traps to watch for when a vendor does not want you to leave their on-prem product.

Line-of-business app migration paths at a glance

Path	Best for	Effort	Risk	Long-term cost
Replace with SaaS	App with a mature cloud-native equivalent	Medium-high (data migration + retraining)	Medium (vendor maturity, feature parity)	Lowest (no infrastructure to run)
Host existing app in cloud (lift-and-shift)	Vendor-supported, no SaaS option	Low-medium (move VM, validate)	Low-medium (latency, license model)	Medium (you still operate the app)
Keep on-prem, integrate with cloud	Vendor-locked, latency-bound, or regulated	None for the app, ongoing for integration	Low for the app, hybrid overhead for the integration	Medium-high (on-prem lifecycle continues)
Repurpose / rebuild from scratch	Custom internal app with no maintainer	Very high	Very high	Variable

Most businesses end a 6-month LOB migration with two or three apps replaced by SaaS, one or two lifted-and-shifted to cloud VMs, and one or two staying on-prem deliberately. That mixed outcome is the norm, not a failure.

For the strategy decision (per workload), lift and shift vs re-platform vs re-architect covers the framework. This article focuses on the application-side execution: how to evaluate, plan, and run the migration once strategy is decided.

What counts as a line-of-business application

LOB apps are the software that runs the actual operation of the business – not the email, not the office productivity tools, not the IT plumbing. The systems where the day-to-day work happens.

Common categories at SMB scale:

• ERP / financial. QuickBooks Enterprise, Sage 50/100/300, Microsoft Dynamics GP/SL/NAV, NetSuite, Acumatica.
• CRM. Salesforce, HubSpot, Microsoft Dynamics CRM, Zoho, vertical-specific CRMs.
• Practice / case management. Clio (legal), PracticeMaster, AbacusLaw, Centerbase, Kareo, Athenahealth, eClinicalWorks (medical).
• Industry-specific software. Manufacturing ERPs (Plex, Epicor, Global Shop), construction management (Procore, Buildertrend), accounting/tax software (UltraTax, Lacerte, ProSeries), real estate (Yardi, AppFolio), logistics, retail POS, etc.
• Document management. iManage, NetDocuments, Worldox, M-Files.
• Time and billing. Centerbase, TimeSolv, Clio billing module.
• Custom internal apps. Built by someone who left the business in 2015 and nobody has touched the code since.

If the business runs on it and the people who use it would know within an hour if it stopped working, it is an LOB app.

The reason these are the hardest part of cloud migration is that they are the most expensive to replace, the most vendor-dependent, the most data-heavy, and the most resistant to change because the people who use them are the ones who keep the business running. Email is forgiving. The practice management system that touches every billable hour is not.

Path 1: replace with SaaS

The most common path for SMBs, and usually the right answer when a mature SaaS equivalent exists.

When SaaS replacement is the right answer

• The vendor has a SaaS product with feature parity (or close enough) to what you currently use.
• Your customizations are not so deep that re-implementing them costs more than the value they deliver.
• The SaaS pricing math works out at your user count.
• The vendor has a credible data migration path from on-prem to cloud.
• Your industry is well-served by SaaS (most professional services and most general business categories are at this point in 2026).

How to evaluate a SaaS replacement honestly

This is where SMB migrations go wrong. The sales demo always looks great. The reality, six months in, is often that the SaaS version is missing 15% of what your team relied on – and that 15% is the part that actually mattered.

Get the feature gap audit in writing.

Make a list of every feature your team uses in the on-prem version. Walk through the SaaS version with the vendor and mark each as “yes,” “yes but different,” “no,” or “roadmap.” Focus on the workflow steps people do dozens of times a day – those are where missing features hurt.

Test with real data.

Insist on a sandbox environment with a representative subset of your real data (anonymized if needed). Spend at least two weeks having actual users do their actual work in it. Demos hide friction; daily use exposes it.

Validate the data export path – both directions.

Before you commit, confirm two things: (1) you can export your existing data from the on-prem version in a format the SaaS can ingest, and (2) you can export from the SaaS later in a format you could move elsewhere. The second one matters because vendor lock-in in cloud is real – you do not want a one-way migration.

Look at the SaaS version’s release cadence and roadmap.

Some vendors have a thriving SaaS product. Others have a SaaS product that is being kept on life support while engineering effort goes back into the on-prem flagship. Look at the release notes from the past 18 months. If the SaaS version has not had a meaningful feature update in that window, ask why.

Check the contract terms.

Annual auto-renewal, price escalation clauses, data ownership, data portability, exit terms. SaaS contracts have different traps than on-prem licenses. The right time to negotiate is before you sign, not when you are trying to leave.

Talk to two reference customers similar to your business.

Not the customers the vendor offers – ask for references at your size, in your industry, who have been on the SaaS version for at least 12 months. The 6-month-in customers are still in the honeymoon. The 18-month-in customers know what is broken.

Data migration from legacy apps

This is the hard part of SaaS replacement.

The export-import gap.

The on-prem app exports data in its format. The SaaS imports data in its format. The gap between the two is where 80% of the migration work happens. Common patterns:

• Custom fields on the on-prem side that have no equivalent on the SaaS side. Decision: drop, map to closest analog, or stash in a notes field.
• Reference data (lookup lists, codes, taxonomies) that needs to be reconciled before transactional data can land.
• Historical data (closed cases, invoices from 2018) that may not be worth migrating – depending on the audit / legal retention requirements.
• Attachments and binary data (PDFs, images, scanned documents) that often need a separate migration path from structured data.
• Audit trail / change log data that almost never migrates, because the SaaS audit log structure is different.

Reconciliation is mandatory.

After data lands, you need to verify it. Row counts on both sides. Spot-check 50 random records and confirm every field migrated correctly. For financial data, run a balance reconciliation – the trial balance on the new system on day 1 should match the trial balance on the old system on cutover day, to the penny.

Plan for data corrections after cutover.

No data migration is perfect. Allocate time for the first 30 days post-cutover to be partly about cleaning up data that did not come across right. Have a process: users flag the issue, IT or the vendor fixes the underlying data, the corrected version is documented.

Some data should not migrate.

Migration is a forcing function for cleanup. Inactive client records from 2014, draft invoices that never got sent, test transactions, accounts that should have been closed years ago. Use the migration as the moment to retire what should have been retired.

What this typically takes

For an SMB practice management or ERP migration to SaaS:

Phase	Hours	What happens
Evaluation	40 to 80	Feature gap audit, sandbox testing, reference calls, contract review
Data prep	40 to 120	Cleanup, reference data reconciliation, custom field mapping decisions
Migration execution	60 to 200	Export, transform, import, reconciliation, cutover
Training and adoption	20 to 80 per team	New workflows, new UI, new reports
Post-cutover stabilization	40 to 100 (first 60 days)	Data corrections, edge case fixes, retraining where needed

A typical 40-person SMB SaaS migration for a single LOB app lands in the 200 to 600 hour range, plus license/subscription cost. The biggest budget killer is underestimated training time – the new system has different workflows, and the people who used the old system fluently for 8 years take 4 to 12 weeks to get productive on the new one. Plan for the productivity dip.

Path 2: host the existing app in cloud

Sometimes the SaaS version does not exist, is not mature enough, or does not match your customizations. In that case, the next best path is to take the existing on-prem app and run it on cloud infrastructure.

When lift-and-shift is the right answer

• The vendor only ships an on-prem product, but the app runs on Windows or Linux servers that can be virtualized.
• The vendor explicitly supports the app running on cloud VMs (most LOB vendors now do, even if reluctantly).
• The customizations or integrations to the on-prem version would cost more to re-implement on a SaaS than to keep running.
• The hardware refresh is imminent and a SaaS evaluation is not realistic in the timeline.
• You want to depreciate the existing app over the next 24-36 months while you evaluate alternatives, and lifting it to cloud removes the immediate hardware problem.

Lift and shift vs re-platform vs re-architect covers the strategy choice in detail. The execution side, specific to LOB apps:

Vendor support: get it in writing

Some vendors are openly supportive of cloud hosting. Some are openly hostile. Some are passive-aggressive – they will not formally bless it, but they will not actively block you either, and you find out which when you open a support ticket.

What to ask the vendor before lifting:

1. Does the license permit cloud hosting? Some on-prem licenses say “single server, single physical location.” Read the actual license, not the marketing. Get clarification in writing if it is ambiguous.
2. Will support work the same? Some vendors will troubleshoot a cloud-hosted version of their app with no issue. Some require you to reproduce every issue on local hardware before they will engage. Some will deflect every issue to “it must be a cloud problem, not our problem.”
3. What is the supported configuration? OS version, database version, RAM, storage tier. Cloud lets you over-provision easily; the vendor’s “supported config” still matters for warranty / support.
4. What about updates and patches? Some vendors push updates that assume specific hardware behaviors. Confirm the patching process works on cloud VMs.
5. What about licensing audits? On-prem license audits are routine for some vendors. Cloud changes the audit profile – virtual core counts, cloud-specific licensing rules, etc.

If the vendor’s answer to any of these is “we do not support that configuration,” you have a decision: comply (which often means staying on-prem), get the answer in writing and accept the risk, or escalate to find a different decision-maker at the vendor.

Lift-and-shift execution specifics for LOB apps

Database side.

Most LOB apps have a database backend – SQL Server, MySQL, sometimes Oracle, occasionally Access (yes, still). Lift-and-shift can mean:

• Move the database to a cloud-hosted VM (matches on-prem behavior closest, easiest vendor support story).
• Move the database to a managed service (Azure SQL Database, AWS RDS) – cheaper to operate but requires vendor support for that path, which not all LOB vendors give.
• Keep the database where it is and only move the application servers to cloud (rare and usually a bad idea due to latency).

Network side.

Users will be connecting to a cloud-hosted app from their offices and homes. The performance characteristics are different from a LAN-hosted app. Some specific concerns:

• Print performance, especially for batch printing (statements, invoices).
• Document scan-and-attach workflows.
• Reports that pull large datasets to render locally.
• Any client-server protocol designed for sub-1ms latency.

The fix is usually some combination of session-based remote access (Citrix, RDS, Windows 365), regional cloud placement (closest region to your offices), and traffic engineering (ExpressRoute, Direct Connect, or just enough bandwidth from the office).

Identity side.

Most LOB apps authenticate against Active Directory. If you have on-prem AD, the cloud-hosted app will need to reach AD. Options:

• Run a domain controller in the cloud, sync with on-prem (extends your AD to cloud).
• Use hybrid identity with Entra Connect so cloud AD is the same identity as on-prem AD.
• For apps that support modern auth (OAuth/OIDC/SAML), reconfigure them against Entra ID directly.

The third option is the cleanest long-term, but most LOB apps still require on-prem-style AD authentication.

What lift-and-shift typically takes

For a single LOB app on a single server:

Phase	Hours	What happens
Pre-migration assessment	16 to 40	Vendor confirmation, license review, sizing
Cloud environment buildout	24 to 60	VM provisioning, networking, identity, backup
Migration execution	16 to 40	Server image migration or fresh install + data restore
Validation	16 to 40	Functional test, performance test, vendor support test
Cutover and stabilization	16 to 40	DNS / connection string changes, post-cutover monitoring

A typical SMB lift-and-shift for one LOB app lands in 90 to 220 hours. Multi-server apps (web tier + app tier + database tier + reporting tier) scale up linearly.

Path 3: keep on-prem, integrate with cloud

Some LOB apps simply cannot move – regulatory constraints, vendor refusal, latency requirements, hardware dependencies. The question becomes: how do you connect the on-prem app to your cloud environment cleanly?

This is hybrid cloud as a deliberate architecture, covered in detail in hybrid cloud for small business: what it is and when it makes sense. The application-side concerns:

Authentication and identity. The cloud users still need to log in to the on-prem app. Modern auth integration (SAML against Entra ID, for apps that support it) beats traditional VPN-back-to-AD for most cases. Conditional access policies, MFA enforcement, and audit logging should apply to the on-prem app the same way they do to cloud apps.

Data flow. If the on-prem app produces data that other cloud systems need (BI tools, reporting, integrations), you need a data pipeline. Options range from “scheduled CSV exports to a cloud storage bucket” to “real-time replication via a cloud data integration platform.” Pick the simplest one that meets the business need.

Backup and DR. The on-prem app gets the same backup discipline as before, but the cloud DR target is now a real option. Many SMBs run on-prem production with cloud-based DR for the LOB app – lower cost than a second on-prem site, fast enough recovery for most use cases. See server backup best practices for small business for the on-prem side.

Lifecycle. Just because the LOB app is staying on-prem does not mean it is exempt from refresh planning. Hardware ages out, OS versions go EOL, vendor support windows close. Build a 3-year lifecycle plan for the on-prem app the same way you would for any production infrastructure.

Path 4: rebuild from scratch (rare)

For custom internal apps with no maintainer, rebuilding from scratch is sometimes the right answer. This is not a “migration” – it is a software development project that happens to coincide with a cloud move.

Indicators that rebuild is right:

• The original developer is unreachable, the code is uncommented, and the dependencies are 12 years out of date.
• The “app” is actually a stack of Excel macros, MS Access forms, and email-driven workflows that should have been replaced years ago.
• The functionality is straightforward enough that a no-code or low-code platform (Power Apps, Airtable, etc.) covers it adequately.
• Off-the-shelf SaaS exists but does not quite fit, and customization budget is real.

Rebuild is the highest-risk path. Budget 5 to 20 times what a lift-and-shift would cost, and 6 to 24 months instead of weeks. The benefit is escape from technical debt that has been accumulating for a decade. The risk is delivering a worse version of the original because you did not have time to capture all the edge cases the original handled.

What to do when the vendor refuses cloud

This is the scenario the brief specifically asks about, and it is more common than vendors admit.

Some LOB vendors actively discourage cloud hosting. Reasons range from legitimate (they have not certified the cloud configuration and cannot support it) to commercial (they want you on their hosted offering, which costs three times more) to anti-competitive (they are protecting an aging on-prem product from cloud-native competitors).

The decision tree:

1. Find out why the vendor refuses. Get the actual reason in writing. “We do not support cloud hosting” might mean “we have not tested it,” which is different from “we have tested it and it does not work,” which is different from “our license forbids it.”

1. Check whether the vendor offers their own hosted version. Many vendors will not let you host their app on Azure or AWS, but they will sell you their own hosted instance for 2 to 4 times the on-prem license cost. Whether that pricing is reasonable depends on your business.

1. Calculate the cost of staying on-prem. Include hardware refresh (every 5 years), OS license, vendor maintenance, your own admin time, backup, DR. The all-in cost of running on-prem is often higher than SMBs realize. Compare it honestly to vendor-hosted or migration-to-competitor costs.

1. Evaluate the competitor landscape. A vendor that refuses cloud hosting in 2026 is often a vendor in slow decline. Their competitors are usually cloud-native and have been actively poaching their customers. The migration cost to a competitor is real, but so is the long-term cost of staying on a vendor whose product is becoming obsolete.

1. Talk to the vendor’s account team about leaving. This sounds counter-intuitive. Sometimes the best path to “yes, we will support cloud hosting” is “we are evaluating your competitor because of this issue.” Vendors who lose customers to cloud move on cloud support faster than vendors whose customers stay no matter what.

1. If you stay on-prem, make it deliberate. Do not stay on-prem because the vendor said no and you gave up. Stay on-prem because you decided the trade-off favors staying. The difference matters: deliberate hybrid gets the operational discipline it needs; resigned hybrid does not.

Common LOB migration mistakes

1. Assuming the SaaS version of your LOB app is “basically the same” as the on-prem version. It is not. The feature gap is always bigger than the demo suggests.
2. Not testing data migration before committing. Discovering on cutover weekend that 8% of your records will not import is a project-killing event.
3. Underestimating training time. Users who have been fluent in the old system for years take weeks to be productive in the new one. Account for the productivity dip.
4. Skipping the reference calls. Two 30-minute calls with similar customers tells you more than 20 hours of vendor demos.
5. Letting the vendor drive the migration timeline. Their goal is to close the deal. Yours is to migrate without breaking the business. The two are not the same.
6. Migrating customizations as-is instead of evaluating which still matter. Half of the customizations in a 10-year-old LOB app exist because of business processes that have changed since. Use the migration to clean up.
7. Not negotiating the contract terms upfront. Auto-renewal, price escalation, data export rights, exit terms. Easier to negotiate before signing than after.
8. Lifting and shifting without confirming vendor support. Discovering 6 months in that the vendor will not support cloud-hosted issues is too late.
9. Treating LOB migration as IT-only. The system runs the business. Business stakeholders need to be in the room for the major decisions, not handed the result.
10. Skipping the post-cutover stabilization period. The first 30 to 60 days are when data corrections, workflow adjustments, and edge-case fixes happen. Plan for it. Do not declare victory at cutover.

How long does an LOB migration take

For a single LOB application:

Path	Calendar time	Hours of work	Cost range
SaaS replacement (simple, single app)	2 to 4 months	200 to 600	$20K to $80K plus subscription
SaaS replacement (complex, integrations)	4 to 9 months	400 to 1,500	$50K to $250K plus subscription
Lift-and-shift to cloud VM	4 to 12 weeks	90 to 220	$10K to $35K plus cloud infrastructure
Stay on-prem with cloud integration	4 to 8 weeks	40 to 120	$5K to $20K plus hybrid overhead
Rebuild from scratch	9 to 24 months	1,500 to 8,000+	$150K to $1M+

These are per-app numbers. A business with five LOB apps does not multiply these by five – some shared overhead, but expect each app to be its own discrete project. The cloud migration checklist for small business covers the project-management overhead that wraps all of these.

How to sequence multiple LOB migrations

Most SMBs have three to seven LOB apps that touch a cloud migration. Trying to do them all at once is the most reliable way to fail. The sequencing that works:

1. One at a time, with at least 60 days between cutovers. Stabilization for app N happens during the assessment phase for app N+1.
2. Replace what is replaceable first. SaaS replacements deliver the most upside (no infrastructure to run, no maintenance). Start with the apps where SaaS is clearly mature.
3. Lift-and-shift the apps that have to move but cannot become SaaS yet. These get out of the server room without changing how users interact with them.
4. Defer the on-prem-only apps to last. They may not need to move at all, and waiting gives the vendor time to ship a cloud version.
5. Audit your on-prem apps annually. The vendor that “does not support cloud” today may have a SaaS version in 18 months. The vendor that has the SaaS version may have brought parity with their on-prem version. Hybrid is not static – revisit the inventory regularly.

How Sequentur can help

If you are mapping out which of your LOB apps to move and which paths to take – or if you are stuck on a vendor that does not want you to leave – schedule a call.