跳到主要内容

对比

Magento 几乎可以建模任何东西。

这可不是敷衍的赞美。对于真正复杂的商品目录、多店铺架构和特殊定价,它比大多数号称能取代它的产品都更强。

真正的问题在于:维持它运转的那支团队让你付出了多少代价,以及这支团队因此而没能去做些什么。

首先,说句实话

Magento 在哪些方面做得比我们好。

建模

  • 极其复杂的商品目录
  • 精细的定价规则
  • 多店铺、多网站架构
  • 原生的深度 B2B 能力

掌控

  • 自托管,完全属于你
  • 任何东西都可定制
  • 一个成熟的企业级生态系统
  • 成熟的集成合作伙伴

规模化

  • 在超大规模商品目录中得到验证
  • 在高订单量下经过充分验证
  • 提供 Enterprise 支持
  • 很容易向董事会证明其合理性

另一面

维持它需要多少费用。

  1. 01

    它需要一个团队

    不是一名开发者——而是一个团队,或一份表现得像团队的代理机构长期合约。这才是真正的成本,而且会反复产生。

  2. 02

    升级是一个项目

    版本升级需要规划、预算,还令人心生畏惧。这正是为什么那么多 Magento 商店运行的版本比他们愿意承认的要旧。

  3. 03

    简单的改动并不简单

    让它能够建模任何事物的那种灵活性,同样也意味着一次商品陈列的调整都得走一遍发布流程。

  4. 04

    缺少了那些新的期待

    店面上的 AI、一款原生应用、货到付款确认。都可以做出来——成本就是你现有的团队。

坦诚面对迁移过程

1

属于较为棘手的那类,我们会事先如实相告。

复杂的属性集、自定义定价规则以及多年积累的定制扩展,并不会在迁移中全部幸存。与其承诺一次干净利落的导入、却在第三周才发现真相,我们宁愿把范围认真评估清楚。参见 /migrate。

"如果 Magento 正在为某种确实复杂的业务建模,而且团队也在,那就留下。买下 MAP 或 Zust,把商店保留下来。" 什么情况下你不该迁移

两者都能在 Magento 上运行,无需更换平台——Zust 连接器正在开发中,MAP 已上线。这正是我们甘愿认输的那种论点。

下一步

把你的属性集和定价规则发给我们。

这才是评估 Magento 迁移范围的诚实做法。我们会告诉你哪些能够直接对应、哪些需要重建,以及现在整件事是否值得去做。

迁移
较难的项目之一
如果团队已经存在
不妨考虑留下来
在 Magento 上运行 MAP
即时上线,无需更换平台