Digital Transformation Case Study

From ERP to Agility

How we helped a trades service company escape the constraints of NetSuite ERP through a phased migration: first to a rapid no-code stack, then to a purpose-built platform designed for their unique operational needs.
Industry
Trades Services
(HVAC, Plumbing, Electrical)
15
Years in Business
$10M
Annual Revenue
30
Employees
A note on privacy To preserve the anonymity of the organization and individuals involved, this document uses aliases: the Company for the organization, the Legacy ERP for their NetSuite implementation, the Bridge Stack for the interim no-code solution, and the Superior ERP for the bespoke system. No confidential or personally identifying details are disclosed.

01Executive Summary

The Company, a growing trades service business serving both property managers and homeowners, found themselves constrained by a NetSuite ERP implementation that couldn't keep pace with their operational complexity and growth trajectory.

Rather than attempting a risky "big bang" migration to a new system, we executed a two-phase strategy:

This approach delivered immediate operational relief while building toward a sustainable, long-term solution. The Company regained control of their technology, reduced operational friction, and established a foundation capable of supporting their next decade of growth.

02The Challenge: When ERP Becomes a Constraint

The Company had grown from a small local operation into a regional trades service provider with a complex operational model. They serve three distinct customer segments, each with fundamentally different operational rhythms:

Their NetSuite ERP implementation, chosen years earlier as an "enterprise-grade" solution, had become a significant drag on operations.

The hidden tax of per-user licensing One of the most damaging effects of NetSuite's cost structure was the decision it forced: to save money, the Company deliberately kept users out of the system. Technicians who needed job information worked from printed sheets or phone calls instead of accessing the system directly. Office staff shared logins. Managers went without visibility they needed because adding a seat wasn't in the budget. The per-user model didn't just cost money; it actively degraded operations by making system access a scarce resource to be rationed rather than a tool to be used freely.

The pain points

AreaThe Problem
Workflow rigidityNetSuite's workflows were designed for traditional manufacturing and distribution, not field service operations. Customizing them to match the Company's dispatch, scheduling, and job-costing model required expensive consultants and still felt like forcing a square peg into a round hole.
Field usabilityTechnicians in the field needed mobile-friendly interfaces to update job status, capture photos, and record materials used. NetSuite's mobile experience was clunky and slow, leading to incomplete data and delayed invoicing.
Tri-segment complexityThree distinct business lines (B2B projects/turns, B2B maintenance, and B2C homeowners) each required different billing cycles, communication styles, pricing models, and workflow pacing. NetSuite's rigid structure made managing these distinctions painful.
Integration limitationsConnecting NetSuite to the Company's scheduling software, GPS fleet tracking, and communication tools required middleware that was expensive to build and fragile to maintain.
Escalating costsNetSuite's pricing model created compounding pressure: annual subscription increases, per-user licensing fees, and additional charges for modules that should have been core functionality. Every new capability came with a new line item.
The core realization The Company wasn't getting value from NetSuite's "enterprise" features; they were paying the enterprise tax while fighting the system to do basic operational tasks their way. The ERP that was supposed to enable growth had become the obstacle to it.

Why not just "fix" NetSuite?

The Company had already invested significantly in NetSuite customizations. The question wasn't whether more customization was possible; it was whether it was wise. Every custom script and workflow increased the maintenance burden and made future upgrades riskier. The platform was becoming a liability precisely because of the effort invested in making it work.

A clean break, executed carefully, offered a better path forward.

03Phase 1: The Bridge Stack

The first phase delivered operational relief in weeks, not months, using a carefully selected combination of no-code and low-code tools.

Why a bridge solution?

The Company faced a stark choice. Their NetSuite renewal was approaching, and staying meant committing to another year and approximately $100,000 in licensing, fees, and associated costs. But building a fully custom platform takes time, typically 6-12 months for a system of meaningful complexity. The math didn't work: they couldn't justify the NetSuite expense, but they couldn't wait a year for a replacement either.

The answer was a 60-day sprint to operational independence. We needed to deliver a functional replacement for NetSuite's core workflows fast enough that the Company could walk away from the renewal without disrupting their business.

The Bridge Stack served three purposes:

The technology choices

Airtable

Role: Relational database
Flexible schema, easy to modify as requirements emerged. Powerful enough for real operations, simple enough for non-technical staff to understand.

Stacker

Role: User interfaces
Built custom portals for office staff, field technicians, and even customer-facing views, all connected to Airtable, without writing code.

Make.com

Role: Automation
Connected the Bridge Stack to existing tools (email, SMS, calendar, accounting) and automated workflows like status notifications and invoice generation.

What we built

CapabilityImplementation
Job managementCustom Airtable bases tracking jobs from request through completion, with views tailored for dispatchers, technicians, and managers.
Customer recordsUnified customer database distinguishing property manager accounts from homeowner records, with relationship tracking for properties.
Field mobile appStacker-built mobile interface for technicians: job details, status updates, photo capture, materials logging, time tracking.
Dispatch boardVisual dispatch interface showing technician schedules, job assignments, and geographic routing.
Automated notificationsMake.com scenarios triggering communications at key workflow stages (appointment confirmation, technician en route, job complete).
Reporting dashboardsAirtable interfaces aggregating operational metrics: jobs by status, revenue by segment, technician utilization.
Meeting the deadline The core Bridge Stack was operational within 6 weeks of project kickoff, comfortably ahead of the 60-day deadline. The Company declined their NetSuite renewal and never looked back. Additional capabilities were added incrementally over the following months as the team identified new needs.

The Bridge Stack's limitations

The no-code approach was intentionally a bridge, not a destination. As the Company grew and requirements solidified, the Bridge Stack's limitations became apparent:

These limitations were expected. The Bridge Stack bought time and provided invaluable learning about what the bespoke platform needed to do.

04Phase 2: The Bespoke Platform

With operational pressure relieved and requirements validated, we began building a purpose-built platform designed specifically for the Company's operational model.

Design principles

The lessons from both the NetSuite experience and the Bridge Stack informed the platform's design:

Operations-First

Built around the daily reality of running a trades service business (dispatch, field work, invoicing) rather than forcing operations into a generic ERP model.

Tri-Segment Native

All three business lines (B2B projects, B2B maintenance, B2C homeowners) as first-class concepts. Different billing cycles, workflow pacing, communication styles, and approval paths built into the core model.

Field-Friendly

Mobile experience designed for technicians wearing gloves in an attic: large touch targets, offline capability, minimal typing required.

Integration-Ready

Clean APIs and webhook support for connecting with scheduling tools, accounting systems, fleet tracking, and future services yet to be adopted.

Core capabilities

DomainKey Features
Customer ManagementUnified customer database with property manager hierarchies, property portfolios, homeowner records, and full service history. Smart distinction between billing contacts and service locations.
Job LifecycleComplete workflow from service request through completion and invoicing. Status tracking, approval gates for B2B accounts, automated follow-ups, and warranty tracking.
Dispatch & SchedulingVisual dispatch board with drag-and-drop assignment, technician skill matching, geographic optimization, and real-time availability tracking.
Field OperationsNative mobile application for technicians: job details, checklists, photo documentation, materials and time capture, customer signatures, and offline support.
Pricing & InvoicingFlexible pricing engine supporting flat-rate, time-and-materials, and contracted rates. Automated invoice generation with configurable approval workflows for large jobs.
Reporting & AnalyticsOperational dashboards, financial reports, technician performance metrics, and customer segment analysis. Data warehouse integration for advanced analytics.
Why tri-segment matters A turn coordinator managing a 20-unit renovation has different needs than a property manager requesting an emergency plumbing repair, and both differ from a homeowner scheduling routine HVAC maintenance. The platform treats these as fundamentally different operational contexts with distinct workflows, billing models, and communication cadences, not just flags on a generic customer record.

05Architecture & Technology Choices

The bespoke platform was built on a modern, maintainable stack chosen for longevity, team familiarity, and operational fit.

Technology stack

LayerTechnologyRationale
Backend frameworkLaravel (PHP 8.x)Mature, well-documented framework with excellent tooling. Large talent pool for future team growth.
DatabasePostgreSQLRobust database with strong support for complex queries, JSON for flexibilty, and proven scalability.
Frontend (Web)Vue.js + Inertia.jsModern reactive UI without the overhead of maintaining a separate API. Server-driven routing with client-side interactivity.
Mobile app (current)Progressive Web AppMobile-optimized interface providing cross-platform access. Native app development is on the roadmap.
APIRESTful + GraphQLREST for simple integrations, GraphQL for complex queries from the mobile app and reporting tools.
HostingAWS (ECS/RDS)Scalable cloud infrastructure with managed database services, proven reliability, and cost-effective at the Company's scale.
Background jobsLaravel Queues + RedisAsynchronous processing for notifications, report generation, and integration syncs without blocking user operations.

Accounting: the QuickBooks decision

One of the first questions when leaving NetSuite is: where does accounting go? NetSuite's strength is its unified financial and operational data. Replacing it means splitting those concerns.

We chose QuickBooks for the accounting layer. The rationale was simple:

The Superior ERP handles operational data (jobs, customers, scheduling, field operations) and syncs financial transactions to QuickBooks for invoicing, payments, and reporting. This separation of concerns keeps each system focused on what it does best.

Integration architecture

A key lesson from the NetSuite experience was the importance of clean integration boundaries. The platform provides:

Avoiding integration debt Rather than building point-to-point integrations that become maintenance nightmares, the platform exposes clean APIs and events. Third-party connections are built on these public interfaces, making them easier to maintain and replace.

06Data Migration Strategy

Migrating from NetSuite through the Bridge Stack to the bespoke platform required careful data handling at each stage.

Migration timeline

NetSuite → Bridge Stack

Extracted core data (customers, jobs, invoices) via NetSuite's SuiteScript APIs and CSV exports. Transformed and loaded into Airtable with Make.com handling the ETL orchestration. Historical data preserved but not all legacy fields carried forward.

Bridge Stack operational period

New data entered directly into Airtable/Stacker. Continued refinement of data model based on operational learnings. Identified data quality issues and cleaned up legacy inconsistencies.

Bridge Stack → Bespoke Platform

Built comprehensive migration scripts to transform Airtable data into the new schema. Ran parallel systems during validation period. Cutover executed over a weekend with rollback plan ready.

Post-migration

Bridge Stack maintained in read-only mode for 90 days for reference. All integrations pointed to new platform. NetSuite finally decommissioned after data retention requirements satisfied.

Data quality as a feature

Each migration stage was an opportunity to improve data quality:

The bespoke platform launched with cleaner, more consistent data than the Company had ever had in NetSuite.

07Outcomes & Business Impact

The migration delivered measurable improvements across operations, user experience, and cost structure.

Operational improvements

MetricBefore (NetSuite)After (Bespoke)
Time from job completion to invoice3-5 days (manual process)Same day (automated)
Field data capture rate~60% (technicians avoided the system)95%+ (mobile app adoption)
Dispatch efficiencyPhone calls + spreadsheetsReal-time visual dispatch
Customer communicationManual, inconsistentAutomated at every stage
Report generationHours (consultant required)Minutes (self-service dashboards)

Cost structure

Perhaps more importantly, the Company no longer makes technology decisions based on seat counts. Every technician, dispatcher, and manager who needs system access has it. The platform serves the business instead of the business rationing access to the platform.

Strategic value

Competitive advantage

The platform now reflects the Company's unique operational model rather than forcing them into a generic ERP mold. This operational excellence differentiates them in sales conversations.

Agility

New capabilities can be built in weeks, not months. The Company can respond to market opportunities and customer requests without waiting for a vendor roadmap.

Data ownership

Full access to all operational data enables advanced analytics and business intelligence that wasn't possible when data was locked in NetSuite's schema.

Ongoing support model

The Company now has an internal IT team that manages day-to-day platform operations. We continue to support that team with architecture guidance, complex feature development, and knowledge transfer. This model gives the Company ownership and control while maintaining access to the expertise that built the system.

What's next

The platform continues to evolve. Current roadmap priorities include:

08Lessons Learned

What worked well

What was challenging

Cautionary note No-code tools are powerful, but they're not free of lock-in. When we migrated from the Bridge Stack to the bespoke platform, we still had to extract and transform data. The no-code vendors' export capabilities varied. Plan for eventual migration even when you're building a "temporary" solution.

09Conclusion & Recommendations

The Company's journey from NetSuite to a bespoke platform demonstrates that escaping an ill-fitting ERP is achievable with the right approach.

When to consider this path

A similar migration strategy may be appropriate when:

Recommendations for similar projects

  1. Start with a bridge. Unless you have perfect requirements clarity (you don't), a rapid no-code implementation teaches you what you actually need. It's cheaper to learn by building than by specifying.
  2. Plan for two migrations, not one. Bridge → Bespoke is a real migration. Budget time and effort for it. The bridge is not the destination.
  3. Involve users early and often. The people who use the system daily will surface requirements and issues that no planning document captures.
  4. Invest in data quality during migration. Migration is an opportunity to clean up years of accumulated data inconsistencies. Take it.
  5. Budget for change management. Technology is the easy part. Getting people to change how they work is harder. Plan for training, documentation, and support.

Final Thought

The Company didn't just replace one system with another. They fundamentally transformed their relationship with technology, moving from a posture of accommodation to one of ownership. For years, their business had bent itself around the limitations of their ERP, accepting friction as the cost of "enterprise-grade" software. That era is over.

What made this transformation possible wasn't just better technology; it was a willingness to question assumptions that had calcified into constraints. The assumption that "enterprise" software was inherently better. The assumption that customization debt was inevitable. The assumption that operational complexity required operational suffering. Each of these beliefs, once examined, turned out to be optional.

The phased approach proved essential. By building a bridge before attempting the final crossing, the Company learned what they actually needed rather than what they thought they needed. Requirements that seemed critical during planning turned out to be artifacts of the old system's limitations. Capabilities that no one had thought to ask for emerged as obviously necessary once people started working in a more flexible environment.

Today, the Company's technology works the way they work, not the other way around. New capabilities are measured in weeks, not quarters. Changes that once required consultant engagements now happen in-house. And perhaps most importantly, the team that runs the business now sees technology as a lever they can pull, not a weight they must carry. That shift, from technology as obstacle to technology as advantage, is the real outcome of this engagement.