Migration from a custom-built B2B portal to Magento — how risky?

Q: Migration from a custom-built B2B portal to Magento — how risky?

Common path. Risk is real but quantifiable.The typical custom-portal stack: Laravel / Django / Rails app + MySQL/Postgres + manual ERP scripts. Built 5–10 years ago, hard to hire for, no upgrade path, every new feature is a custom build. Maintenance is a tax on the dev team.Migration plan (12–20 weeks):Data audit (week 1–2): companies, buyers, customer-group pricing rules, requisition lists, open quotes, AR balances. Map to Magento entities — companies → B2B Companies module, buyers → customers, segment pricing → customer-group prices.Feature parity matrix (week 2): what does the custom portal do that Magento doesn’t out-of-box? Build the gap list. Usually 6–12 items, 3–5 of which need custom modules.Magento + extensions setup (week 3–5): base Magento, Hyvä theme, B2B extensions, ERP connector, payment gateways.Custom-portal data export (week 6): SQL dumps + CSV exports of all customer + order + pricing data. Validate counts.Magento data import (week 7–9): via dataflow / API / direct SQL. Spot-check 100 customers + 50 orders for accuracy.Parallel run (week 10–14): both portals live. New orders go to Magento; old portal is read-only for AR / reporting. Buyers get a "we’ve moved" email + reset-password link.Cutover (week 15): DNS flip. Old portal stays read-only for 90 days for any AR queries.Stabilisation (week 16–20): bug fixes, buyer training, ERP sync tuning.Risk hotspots: (1) password migration — you can’t move hashes if the algos differ; force a reset email at first login. (2) saved-card tokens — need to re-tokenise at the new gateway via account-updater service. (3) custom-portal-only URLs — build a redirect map covering >95% of indexed traffic before DNS flip.

Question

Accepted Answer

Common path. Risk is real but quantifiable.

The typical custom-portal stack: Laravel / Django / Rails app + MySQL/Postgres + manual ERP scripts. Built 5–10 years ago, hard to hire for, no upgrade path, every new feature is a custom build. Maintenance is a tax on the dev team.

Migration plan (12–20 weeks):

Data audit (week 1–2): companies, buyers, customer-group pricing rules, requisition lists, open quotes, AR balances. Map to Magento entities — companies → B2B Companies module, buyers → customers, segment pricing → customer-group prices.
Feature parity matrix (week 2): what does the custom portal do that Magento doesn’t out-of-box? Build the gap list. Usually 6–12 items, 3–5 of which need custom modules.
Magento + extensions setup (week 3–5): base Magento, Hyvä theme, B2B extensions, ERP connector, payment gateways.
Custom-portal data export (week 6): SQL dumps + CSV exports of all customer + order + pricing data. Validate counts.
Magento data import (week 7–9): via dataflow / API / direct SQL. Spot-check 100 customers + 50 orders for accuracy.
Parallel run (week 10–14): both portals live. New orders go to Magento; old portal is read-only for AR / reporting. Buyers get a "we’ve moved" email + reset-password link.
Cutover (week 15): DNS flip. Old portal stays read-only for 90 days for any AR queries.
Stabilisation (week 16–20): bug fixes, buyer training, ERP sync tuning.

Risk hotspots: (1) password migration — you can’t move hashes if the algos differ; force a reset email at first login. (2) saved-card tokens — need to re-tokenise at the new gateway via account-updater service. (3) custom-portal-only URLs — build a redirect map covering >95% of indexed traffic before DNS flip.