The Fast-Growing SME That Migrated from Legacy to a Proper ERP System

Let’s roll the clock back, shall we?

It’s the early days of eCommerce – back when selling online was still considered risky, impractical, and a little bit… weird. Amazon was still mostly a bookstore. Shopify wasn’t even in a garage yet.

And yet, here’s this small-but-fierce specialty electronics retailer specializing in spy gear, surveillance, and personal security devices. They had multiple physical locations and a loyal customer base that trusted them for high-end, niche gear. And here’s the kicker… they were already selling online before it was cool.

But behind the scenes, their business looked a lot like a chaotic scatter of mismatched puzzle pieces, each a siloed legacy systems: old point-of-sale software, disconnected inventory management, and a creaky eCommerce platform all patched together like Frankenstein’s monster. Data didn’t match, orders got lost, and stockouts happened even when shelves were full.

Scaling up? Impossible without everything falling apart.

This was the legacy puzzle they needed to solve – transforming disconnected pieces into a solid, unified whole.

The Situation: Migrating from a Legacy System to a Real ERP

Think of it like running a Formula 1 car… but with parts from three different decades. Sure, it moves, but push it harder and something breaks.

The company needed a modern, fully integrated enterprise resource planning platform – and they needed it fast. But here’s the list of challenges they faced after rapid growth from a single shop to a chain of several salons spanning half the country, plus a brand-new central warehouse.

Challenges Everyone Knows About:

• Near-zero tolerance for downtime – customers weren’t going to wait for “maintenance windows.”

• Lean budget – this was SME reality, not a Fortune 500 blank check.

• Multiple stakeholders – store managers, warehouse staff, eCommerce teams, and owners all had different needs and priorities.

• Personnel management chaos – processes were scattered across multiple Excel files, covering onboarding, HR, leave, and salary entitlements, with separate silos for each showroom, the central warehouse, HQ, and a team of service technicians.

• Outdated sales tracking – originally based on periodic email reports, later consolidated into a massive Excel spreadsheet thanks to one dedicated person’s efforts.

• No customer journey tracking – no tools for calculating customer lifetime value or building long-term relationships with key B2B accounts.

• Disjointed inventory systems – showroom inventory wasn’t integrated with the central warehouse or courier systems.

• Sales-to-inventory lag – several days could pass between a sale and an inventory update.

• No delivery verification – no process for confirming showroom deliveries or technician pickups from distribution points.

• No demand forecasting – inventory planning was reactive, with slow response to market demand for new products.

• Marketing misalignment – HQ campaigns weren’t coordinated with showroom-level efforts, and marketing wasn’t in sync with warehouse ordering.

Hidden Challenges

• No data integrity – no backups, outdated records, inconsistent formats, and no validation during data entry (a simple typo could create a “new” product).

• Heavy compliance burden – significant administrative effort was needed to manage personnel in line with legal regulations.

• Technician coordination overhead – dedicated staff were required just to manage installer and service technician schedules.

• Inconsistent management practices – each store operated under its manager’s own processes.

• Poor product information – descriptions for the website and tenders were incomplete, vague, or inconsistent, entered into different systems by different people using different sources.

My Role: From Translator to Leader

My role was never simply about technology. I didn’t just “parachute in as the tech guy.” My job was to be a translator – bridging the gap between technology, the business’s strategic needs, and the people who would use the new system every day. My mission was to make the entire migration work without disrupting the core functions of the company.

My first step was to map the entire value stream along with all the business processes and data streams. I sought to understand where time was being wasted, where error traps existed, and which processes truly added value versus those that were simply a result of “how we’ve always done it.” This deep dive into the company’s operational DNA was crucial for identifying inefficiencies and setting the stage for a more streamlined future.

From this analysis, I designed a migration strategy to move the company from its legacy chaos to an integrated, harmonious system. We weren’t just ripping out the old system in one go. Instead, I built a phased rollout, starting with pilot locations to test for kinks and refine processes before scaling up. This approach minimized risk and allowed us to adapt in real time.

From this analysis, I designed a migration strategy to transition the company from legacy chaos to an integrated, harmonious system.

I began this journey as a business analyst and IT consultant, but the project’s demands quickly evolved my role. I ultimately became the project manager and the de facto leader of this hardcore business and technology project.

This was in an era before modern tools like proper Business Process Automation, no-code eCommerce solutions, or Large Language Models were commonplace. I was introducing concepts like version control with Git to the IT team, lean management principles to department managers, and value stream mapping to the company’s leadership. It was a project that required not just technical expertise but a fundamental shift in how the entire company approached business and technology.

The People Side of Technology Migrations

At its core, a technology migration isn’t about the software or hardware-it’s about the people who will use it. I learned this firsthand as the business analyst and project manager leading a critical system transition. My first priority was building the right cross-functional team. I brought together a backend developer with prior experience in enova360, two system administrators and their boss the IT department manager, the eCommerce manager, and the warehouse manager. This diverse group was the engine of the entire project. We had to be adaptable and lean, as we often made changes on a weekly basis, a pace that was essential for our success.

Simultaneously, I was deep in negotiations with various ERP vendors. Ultimately, we selected enova365 business management software from Soneta Sp. o.o. This decision was about more than just picking a product; it was a complex negotiation to secure favorable licensing terms, expert help with data migration, seamless integration with our existing systems, and, most importantly, dedicated ongoing support. This was a particular challenge given our tight SME budget and the corporate-level expectations from the owners, who were used to the rapid velocity of startup projects. It was a high-stakes balancing act to deliver a robust solution while operating within significant financial constraints.

Execution: The Migratory Process

The execution phase was a methodical, two-pronged attack: first, the meticulous preparation of our data, and second, a strategic, company-wide soft launch. We began with data cleansing and mapping, a painstaking process that formed the bedrock of the entire migration. Our legacy systems were a labyrinth of mismatched SKUs, outdated customer records, and inconsistent product descriptions. We couldn’t simply “lift and shift” this data; we had to transform it. This involved defining a clear, standardized data model for the new ERP and then painstakingly mapping every single field from our old systems to its new home.

To ensure data integrity, we developed a series of automated validation scripts. These scripts were our early warning system, designed to catch errors before they could contaminate the new database. They checked for everything from mismatched data types and missing fields to logical inconsistencies, saving countless hours of manual work and ensuring the quality of our data from the very beginning.

With the data prepared, we moved to the soft launch. This wasn’t a pilot in a single location; it was a simultaneous rollout across our entire ecosystem – eCommerce, all retail stores, and the warehouse. For two intense weeks, both the old and new systems ran in parallel. This “dual-system” approach was a real-world stress test, allowing us to identify and resolve issues without disrupting core operations. We used this period to fine-tune workflows, train staff, and collect feedback, all while ensuring business continuity. After this critical testing period, we performed the final data transfer and executed the big, company-wide rollout, confident that the system was robust and ready to handle our entire business.

Your text is already strong, but I’ve polished it for flow, consistency, and punch while keeping your “Peter Zeihan meets war room” tone intact. Here’s the corrected and tightened version:

Results: My Take

If you want to know whether an ERP migration worked, you don’t start with a feel-good speech about “digital transformation.” You start with a table – because numbers tell a story your marketing department never will.

The before/after format forces brutal honesty. It strips out excuses and lets anyone – a CEO, a shop floor supervisor, or a skeptical investor – see if the pain was worth it.

Baseline → Target → Achieved

Translating digits into cause-and-effect

• Order Accuracy: This isn’t just about happy customers – it’s about cash flow and fewer returns. We went from a one-in-twelve chance of an error to virtually flawless. That’s not incremental improvement; that’s market differentiation.

• Inventory Turnover: Less capital trapped in storage, more flexibility to react to market swings. Real-time purchasing-to-sales communication was the key – a prerequisite for lean inventory.

• Downtime: Fourteen hours a month was essentially a part-time role dedicated to apologizing for outages. Now? Less than one hour. That’s resilience by design.

• Hours Saved: 820 hours a month freed isn’t idle time; it’s capacity redirected to growth, not firefighting.

• Payback Period: Textbooks said 36 months. We hit it in 11. That’s rare – the kind of number that makes a board lean forward and consultants start eyeing that new four seasons tent for Toyota Hilux overlander they’ve always dreamed about!

Bottom line: These aren’t just performance stats; they’re a map of how we moved from reactive firefighting to proactive scaling. In business, if you don’t secure operational bottlenecks, you lose market share.

ERP migrations done right aren’t about technology – they’re about strategic positioning. The baseline shows your vulnerabilities. The target defines your desired territory. The “achieved” column? That’s the high ground – taken and held.

Data Quality KPIs – The War You Can’t Afford to Lose

ERP migrations don’t fail because developers can’t code an API or project managers skip stand-ups. They fail because your data is a minefield – decades of typos, duplicates, mismatched IDs, and “creative” workarounds.

If your value stream is the front line, data quality is your supply chain – and when the supply chain collapses, the war ends before the real fight begins.

Baseline → Target → Achieved (Data Quality)

If ERP projects were geopolitical conflicts, data migration would be the logistics war – unglamorous, but decisive. Nobody builds statues to quartermasters, yet without them, the front collapses in hours.

I’ve seen countless failed migrations where the tech was flawless – integrations, dashboards, workflows all ready – but the moment systems went live, rot surfaced:

• Shipments failed because an address field hid a carriage return.

• Pricing broke because the old system let sales reps type “Special” in a numeric discount field.

• Warehouses froze because “SKU-123” and “SKU_123” weren’t recognized as the same product.

What separates success from disaster

• Appoint dedicated data stewards from day one – not “as we go.”

• Cleanse and standardize data before a single record moves.

• Stress-test your conversion process like NATO war games – simulate failure, fix, simulate again.

On go-live day, your ERP won’t care about intentions – only whether the data fits the rules.

Why This Is the War Before the War

If your master data is wrong, your ERP will make very accurate mistakes – at speed and scale. That’s why elite implementations spend half the project budget on cleansing, standardizing, and validating data before the shiny new system even launches.

Once your conversion success rate breaches the high 90s and your defect rate drops below 1%, you’ve secured your supply lines, you can call your Lean Black Belt master and call it a proof! And with supply lines secured, everything else becomes faster, cheaper, and easier.

In every ERP case study worth reading, these KPIs were the decisive factor between hitting payback in under XYZ months… or sinking into an endless “stabilization phase” where users curse the system daily.

Why It Worked

It wasn’t just a tech upgrade. It was a Lean management play that aligned people, processes, and technology to serve the business – not the other way around.

By the time eCommerce exploded in popularity, this SME wasn’t scrambling to catch up. They were already running on infrastructure built to scale. The migration had turned them from an early adopter into an entrenched market leader.

If I were to sum it up?

We took a company running on stitched-together legacy systems, kept it fully operational during the transition, cut costs, improved efficiency, and positioned it years ahead of its competitors – all before “digital transformation” became a buzzword.

And that’s exactly the kind of forward-looking operational leadership I bring to the table.