Ghori Trading — migrating off Dynamics 365 BC to a unified Odoo platform.
Ghori Trading LLC is an FMCG trading company managing multi-vendor sourcing, inventory-intensive operations, and both offline and online sales channels. They had been running on Microsoft Dynamics 365 Business Central — a real enterprise ERP — but the system wasn't fitting how the business actually operated. Galaxy migrated them to Odoo and rebuilt the operation around it: core business setup, accounting, inventory, costing, and full Amazon marketplace integration.
Ghori Trading was running on Microsoft Dynamics 365 Business Central — a credible enterprise ERP that handles a wide range of mid-market businesses well. For Ghori's specific operation, it wasn't fitting. The licensing was expensive relative to what the team was actually using, customization for FMCG-specific workflows ran into the constraints of Microsoft's framework, and the Amazon marketplace operation was effectively running outside the ERP because the native fit wasn't there.
Most businesses don't migrate off Dynamics 365 BC casually. It's not a tool you outgrow easily, and the switching cost is real — data extraction, historical record migration, retraining a team that's been working in the system for years. Ghori reached the point where the cost of staying was higher than the cost of moving. The everyday friction had accumulated to where the operation was working around the ERP rather than through it.
Compounding the migration question were the operational realities the new system had to handle correctly from day one: multi-vendor sourcing across international suppliers, multi-currency procurement, landed cost handling for imports, dual-channel sales across offline distribution and Amazon (FBA and FBM both), and accounting compliance with regional regulations. The new system couldn't just match what Dynamics did — it had to fit how the business actually wanted to operate.
Migrations from established enterprise ERPs aren't about replacing features. They're about getting to a system the operation can run through, not around. The data move is the easy part — the operational fit is where most migrations stall.
When a business decides to leave an enterprise ERP, the obvious migration targets are other enterprise ERPs. Ghori considered them. SAP Business One would have been a lateral move — different vendor, similar constraints, similar licensing economics. NetSuite was a credible option but priced for businesses larger than where Ghori actually operates. Sticking with point tools — QuickBooks plus a separate Amazon connector plus an inventory system — would have recreated the disconnection that the move to Dynamics was originally meant to solve.
Odoo's fit was structural rather than aspirational. One platform covering company setup, sales, purchasing, inventory, accounting, and Amazon marketplace — with FBA and FBM treated as native channels rather than bolt-ons. The licensing math worked for an FMCG trading operation at Ghori's scale. The open architecture and customization headroom meant the system could be shaped around how the business actually operates rather than constrained by a vendor's framework. The migration from Dynamics 365 BC, while non-trivial, was straightforward enough to do cleanly with the right partner.
Three things made this implementation specifically Galaxy work rather than configuration-only: migrating data and operational state cleanly off Dynamics 365 BC without losing historical continuity, configuring and extending the Emipro Amazon Connector to handle both FBA and FBM workflows reliably, and implementing landed cost functionality that ties properly to multi-currency procurement. None of this is impossible in stock Odoo. All of it requires real engineering depth and migration discipline to land properly.
The implementation ran across five workstreams. The first was the migration off Dynamics 365 BC — the foundation that everything else built on. The next three established the new operational layer. The fifth — Amazon integration — is what turned the system from "another ERP" into a unified commerce operation that handles both channels from one place.
The foundation of the engagement. Extracted vendor, customer, product, and historical transaction data from Dynamics 365 BC. Cleaned, deduplicated, and mapped the legacy data model to Odoo's structure — these aren't one-to-one, and the mapping decisions affect everything downstream. Loaded historical financial state into Odoo with proper opening balances and audit trail preserved. Ran the two systems in parallel during cutover so the team could validate the new system against the source of truth before fully transitioning off Dynamics. Decommissioned access to Dynamics only after the new system was carrying the operation cleanly through at least one full reporting cycle.
Clean migration off Dynamics 365 BC with full historical continuity preserved. Parallel run validation ensured the new system was trusted before the old one was retired.
Full company configuration in Odoo with the operational modules needed for an FMCG trading business. Structured import and validation of vendor and customer master data so partnerships, payment terms, and supplier relationships were operational from day one. Standardized workflows for sales, purchase, and partner management — so the team had clear paths through every transaction type from the start, not patterns invented under deadline pressure.
Faster operational onboarding and system adoption. Improved control and visibility over business relationships and transactions from launch.
Implemented a structured Chart of Accounts tailored for FMCG trading operations. Configured accounting journals with seamless integration into sales, purchase, and inventory modules so financial entries flow from operational activity automatically. Implemented tax configurations aligned with applicable regional regulations. Automated financial reporting and reconciliation within Odoo — replacing the manual month-end assembly that defines most FMCG traders' first years.
Reduced manual accounting effort and reconciliation errors. Compliance and audit readiness established from day one.
End-to-end setup of the Inventory module with structured product categorization across the FMCG catalog. Alignment of costing methods with corresponding accounting entries so inventory valuation stays accurate as goods move through procurement, storage, and sale. Multi-currency handling configured for supplier and purchase transactions across international procurement. Landed cost functionality implemented so duties, freight, insurance, and import-related charges are allocated to inventory at receipt — not booked to spreadsheets and forgotten.
Improved inventory accuracy and valuation transparency. Better cost control, real margin analysis, and reliable stock-and-cost data for decision-making.
The workstream that made this implementation distinct. We integrated Amazon Marketplace directly into Odoo using the Emipro Amazon Connector — configured and extended to handle both fulfillment models reliably. FBA workflows configured to accurately track Amazon-fulfilled orders, settlements, and stock updates flowing back to the central inventory truth. FBM workflows configured to manage merchant-fulfilled orders, deliveries, and invoicing directly from Odoo. Automated synchronization across products and pricing, inventory levels, sales orders and customer data, invoices, and fulfillment status. The result is one operational view of the business across offline distribution and Amazon — not two parallel businesses being manually reconciled.
Centralized management of both FBA and FBM operations within Odoo. Real-time inventory visibility across Amazon and internal warehouses, eliminating the oversells and stock drift that come with parallel-system management.
Migrations off established enterprise ERPs like Dynamics 365 BC fail in predictable ways. Either the data move goes wrong and the new system inherits years of legacy mess, or the data move is clean but the new system gets configured to mimic what the old system did — recreating the misfit that triggered the migration in the first place. Four principles made this implementation different.
Migrate the data, but not the assumptions. Dynamics 365 BC and Odoo have meaningfully different data models. We extracted what mattered and mapped it cleanly to Odoo's structures — but we didn't carry forward configuration decisions that existed because of Dynamics' constraints. The new system was set up to fit how Ghori wanted to operate, not how Dynamics had forced them to operate. Parallel run during cutover was non-negotiable; the old system stayed live until the new one was earning trust through real operational cycles.
Configure the connector to the operation, not around it. Standard Emipro out of the box handles the happy path. Real FBA + FBM operation has edge cases — settlement timing variances, partial fulfillment, returns flowing through different physical paths than outbound, channel-specific pricing rules. Configuring the connector to handle these correctly is the work most implementations skip and pay for later.
Landed cost has to live at the inventory level, not the spreadsheet level. For an FMCG trader importing from multiple suppliers in multiple currencies, the difference between landed cost computed at receipt and landed cost computed by accountants three weeks later is the difference between trustworthy margin reporting and guesswork. We implemented it at the source so every downstream margin number is honest.
One operational view, not two parallel businesses. The Amazon integration didn't bolt a marketplace onto an ERP. It made the marketplace a native channel — inventory, accounting, customer data, and reporting all flow through the same system as the offline business. The owner doesn't need to mentally consolidate two operations at the end of each week. The system has already done it.
Migration projects succeed when you stop treating the new system as a replacement for the old one. Ghori moved off Dynamics 365 BC not to get the same operation on a different platform, but to get a system the operation could actually fit. That's the difference between a migration and a transplant.