Migration

Your catalog will migrate. Your saved cards will not.

Every Magento migration guide covers products, URLs, and themes, and those are the parts that move. The parts that do not are the money: a vault holding tokens that belong to your gateway rather than to you, authorizations that expire on the old processor's clock, and refunds for captured orders that can only be issued where the charge lives. Those three depend on other companies agreeing to help you, so they set your timeline. Scope them first, and get your version's real support date while you are at it, because for Magento Open Source it is about a year earlier than most tables show.

The vault

Magento stores a gateway token, never a card. It is meaningful only to the gateway that issued it.

The cliff

Extended support is an Adobe Commerce benefit. Open Source ends at standard support, and 2.4.6 ends 2026-08-11.

The overlap

Refunds and chargebacks on pre-cutover orders keep the old processor live for months after launch.

published 2026-07-25 · every date below is sourced to Adobe documentation

01Definitions

Four things people mean by Magento.

The support answer, the B2B answer, and the migration answer are all different per edition, so it is worth being precise about which one you run.

Edition	License	Extended support	What that means
Magento Open Source	Free	Not available	The self-hosted code base. No B2B module and no Adobe support contract.
Adobe Commerce	Licensed	Available	Same core plus B2B, staging, segmentation, and Adobe support. Self-hosted or on Adobe's managed cloud.
Adobe Commerce as a Cloud Service	Licensed	Available	The SaaS line introduced in 2025. Versionless and updated by Adobe, and headless-first, so a Luma storefront is rebuilt rather than carried over.
Magento 1	Free	Not available	End of life since June 2020. If you are here from a Magento 1 store, every date below is already behind you.

Adobe acquired Magento in 2018 and the commercial editions carry Adobe's name now, which is why the same store gets called Magento by its developers and Adobe Commerce by its invoice. The code underneath is shared. What is not shared is the support contract, the B2B module, and, as the next section covers, the length of time your version keeps getting security patches.

Magento Open Source is the large majority of installs. It has no Adobe support contract to fall back on, and the person deciding what happens next is usually a developer rather than a procurement committee. If you are on a licensed edition with an account manager and a systems integrator already engaged, the technical sections still apply; the advice about sizing and staffing the work yourself does not.

02The dates

Extended support is not for you.

This is the single most misreported fact about Magento, and it moves most Open Source stores about a year closer to the edge than they think.

Adobe publishes one lifecycle table, and almost every migration article quotes it as though it applies to everyone. It does not. Adobe's release policy is explicit: "Extended support security patches are available to Adobe Commerce customers only. They are not available for the Magento Open Source code base."

So the extended column is a paid-tier benefit. If you run Open Source, your version's life ends at the standard support date, and the friendly-looking date one column to the right belongs to somebody else's store.

Version	Standard support ends	Extended (Adobe Commerce only)	Magento Open Source
2.4.4	2025-04-12	2026-04-14	Unpatched
2.4.5	2025-08-12	2026-08-12	Unpatched
2.4.6	2026-08-11	2027-08-30	Ends 2026-08-11
2.4.7	2027-05-31	2028-05-31	Ends 2027-05-31
2.4.8	2028-05-31	TBD	Ends 2028-05-31
2.4.9	2029-05-31	TBD	Ends 2029-05-31

Two readings of that table matter. 2.4.6 Open Source stops receiving security patches on August 11, 2026, while an Adobe Commerce store on byte-identical code has patches into August 2027. And Open Source stores still on 2.4.4 or 2.4.5 are already past the end: standard support for those ended in April and August of 2025, and the 2026 dates beside them have never applied to the free edition.

None of this means Magento is going away. Adobe ships Open Source on an annual cadence, 2.4.9 arrived on May 12, 2026, and its standard support runs to May 2029. Upgrading is a perfectly good answer, and for a lot of stores it is the right one. The point of the table is that the deadline you are actually working to is probably not the one you wrote down.

Check your own version before planning around thisThese are Adobe's published dates as of the review date at the bottom of this page, and Adobe has moved them before. The lifecycle policy page is the authority, it is linked in the sources, and a date in a blog post is worth exactly nothing against it.

03The thing nobody quotes

Your vault holds tokens that belong to your gateway.

This is the part of a migration that cannot be solved by writing better code, because it needs another company to say yes.

vault_payment_token

entity_id           1042
customer_id         318
public_hash         9f2c1e4a8b...
payment_method_code braintree_cc_vault
type                card
gateway_token       f8k2mn          <- the gateway's, not yours
details             {"cc_last4":"4242",
                     "cc_exp_year":"2029",
                     "cc_type":"VI"}
is_active           1
is_visible          1

The whole durable record of a stored card. Magento holds no card data, by design and correctly.

Stored: A gateway token and a public hash
Not stored: Card number, expiry, or CVV
Belongs to: The gateway in payment_method_code
Portable: Only by processor-to-processor transfer
Needs: Both providers to agree, and to schedule it

Magento's vault does the right thing: it never stores a card. It stores gateway_token, issued by the processor named in payment_method_code, plus a public_hash that is Magento's own handle for the row and some display details like the last four digits. That design is why your PCI scope is small, and it is also why the rows are not yours to move.

A gateway token is a pointer into somebody else's database. Hand it to a different processor and it means nothing. Moving stored cards means the real card numbers move between two PCI-compliant environments, which happens only when your current provider and your next one both agree to run the transfer, assign people to it, and schedule it. Where network tokens are involved the card networks can be in the loop too. It is a commercial negotiation with an engineering tail, and the failure mode is not a bug, it is a provider that stops returning emails.

Nothing about that is Magento-specific, and nothing about it is unusual. What is unusual is how rarely it appears in a migration quote.

What Flint can and cannot take.

The API itself is the answer: this is the entire request body for storing a card, and there is no field in it through which a gateway token, a card number, or a network token could arrive.

curl

curl -X POST https://api.withflintpay.com/v1/payment-methods \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "customer_id": "cus_1kmn0aExample",
    "type": "card"
  }'

Two fields. Neither of them is a card.

201 Created

{
  "data": {
    "payment_method_id": "pm_1kmn0aExample",
    "customer_id": "cus_1kmn0aExample",
    "type": "card",
    "status": "pending",
    "card": null
  }
}

The card arrives from the buyer, in a session the buyer is present for. A stored card is consent, and consent does not transfer with a database row.

POST /v1/payment-methods
customer_id
type

So Flint cannot import your vault either. If your migration depends on carrying stored cards, that conversation belongs with your current processor first, and the answer they give will shape which platforms are even reachable.

04The cutover

Four problems that only exist on the day you switch.

Each of these is invisible in a feature comparison and expensive in production.

01
Refunds for orders you already captured.
A refund needs the charge it reverses, and the new platform never had it. You keep the old gateway account open and reachable for the whole refund and chargeback window, which means two systems live at once and a support team that knows which one to open first.
02
Authorizations that are open on the day you switch.
An authorization is a hold on the issuing bank, placed by one processor, and it expires on that processor's clock. Anything not captured before cutover has to be captured on the old system or released, because the new one has nothing to capture against.
03
Every customer with a card on file.
If the vault does not transfer, each of those buyers has to re-enter a card. For a store with recurring orders or one-click reordering that is not an inconvenience, it is a churn event, and the size of it is the single largest unknown in most migration plans.
04
One accounting month, two settlement sources.
Payouts, fees, refunds, and chargebacks arrive from both processors during the overlap, and neither statement reconciles to your order table on its own. Decide who owns that month's close before you pick a cutover date, not after.

The common thread is that a migration is not an event, it is an overlap. For the length of your refund and chargeback window you are operating two payment systems, reconciling two settlement feeds, and answering support tickets that could belong to either. Budget that period explicitly. Teams that treat cutover as a date rather than a season are the ones still untangling it a quarter later.

05The arithmetic

What the alternatives cost.

Adobe prices by quote and publishes no rate card, so every number in this section is third-party reporting rather than a primary source. Treat them as ranges to test, not as facts.

Staying and upgrading. The cheapest option on paper, and for an Open Source store on a recent version it is usually the correct one. The real cost is whatever your extensions and custom modules charge you at each annual release, which is the number only your own team can estimate.

Moving to a licensed Adobe edition. Vendor and agency reporting puts Adobe Commerce as a Cloud Service licensing in the low tens of thousands per year at the entry tier, rising steeply with revenue, before implementation. Because that line is headless-first, a Luma storefront is rebuilt rather than carried across, so the frontend work lands whether or not you wanted it.

Moving to another platform. Agencies publicly quote mid-market Magento replatforms in the tens to low hundreds of thousands, and the spread is driven by extension count and custom module count rather than by catalog size. None of the quotes we have seen includes the vault transfer or the dual-running period.

Every path off the code base you run today involves rebuilding the storefront. Once you accept that, the question stops being which platform replaces Magento and starts being what you actually need underneath the storefront you are about to write. For some teams that is another platform. For some it is a catalog, an order model, and a payments API, and nothing else.

06The decision

Five questions worth answering first.

In this order. The first one sizes the project and the last one decides who does the work.

01
How many active cards are in your vault?
This is the first number to get, because it sizes everything else. A store with no stored cards has a straightforward migration. A store with tens of thousands has a commercial negotiation ahead of it.
02
Do you have recurring or scheduled orders?
Subscriptions turn a vault problem into a revenue problem. Re-collection campaigns do not recover everyone, and the gap shows up as churn in the month after cutover rather than as a migration line item.
03
Is your storefront already being rebuilt?
If you are moving to a headless-first target, the frontend is rebuilt either way. That is the moment the platform question is genuinely open, because the usual argument for staying is the cost of replacing the head.
04
Does anything about your commerce not fit a store?
Deposits, quotes, service work, events, memberships, or in-app purchases. Storefront platforms model these as workarounds because they are built around a catalog and a cart.
05
Who is doing the work?
If the answer is an agency on a fixed bid, put the vault transfer, the cutover overlap, and the support dates in the statement of work. If the answer is your own engineers, this list is theirs to own.

One scoping note on B2B. Company accounts, negotiable quotes, requisition lists, and shared catalogs are part of the Adobe Commerce B2B module and are not in Magento Open Source, so most Open Source stores doing B2B built it themselves or bought an extension. Net terms, credit limits, and accounts receivable are their own category again, and Flint does not have them. If invoiced net-30 business is how you get paid, that requirement should drive your platform choice, and it will not point here.

07The other side

What the order layer looks like underneath.

Flint is a commerce and payments API. It has no storefront and no themes. What it has is the money layer: the order, the payment, and the record that survives your migration.

Start with the identifiers, because that is where a migration either keeps its history or loses it. Orders take an external_reference_id and arbitrary metadata, so a record can carry both of Magento's identities: the increment_id your customers and support team quote, and the entity_id every API call and foreign key uses.

Magento, for reference

{
  "entity_id": 8891,
  "increment_id": "100000042",
  "state": "complete",
  "status": "complete"
}

Carry both across or you lose the ability to answer what happened to order 100000042.

curl

curl -X POST https://api.withflintpay.com/v1/orders \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Idempotency-Key: import-100000042" \
  -d '{
    "external_reference_id": "100000042",
    "metadata": {
      "magento_entity_id": "8891",
      "magento_store_id": "1"
    },
    "line_items": [
      { "name": "Shelf bracket, oak", "sku": "BRK-OAK-1",
        "quantity": 1,
        "unit_price_money": { "amount": 8900, "currency": "USD" } },
      { "name": "Wall anchor, pack of 4", "sku": "ANC-4",
        "quantity": 3,
        "unit_price_money": { "amount": 2400, "currency": "USD" } }
    ]
  }'

No totals are sent. The reference and metadata travel with the order for the rest of its life.

201 Created

{
  "data": {
    "order_id": "ord_1kmn0aExample",
    "external_reference_id": "100000042",
    "status": "open",
    "payment_status": "unpaid",
    "refund_status": "none",
    "line_items": [
      { "order_line_item_id": "oli_1kmn0aExample",
        "sku": "BRK-OAK-1", "quantity": 1 },
      { "order_line_item_id": "oli_2pqr7bExample",
        "sku": "ANC-4", "quantity": 3 }
    ],
    "pricing_amounts": {
      "subtotal_money": { "amount": 16100, "currency": "USD" },
      "tax_money":      { "amount": 1288,  "currency": "USD" },
      "total_money":    { "amount": 17388, "currency": "USD" }
    },
    "settlement_amounts": {
      "paid_money":        { "amount": 0,     "currency": "USD" },
      "outstanding_money": { "amount": 17388, "currency": "USD" }
    }
  }
}

Subtotal, tax, and total came back computed, and every line has an id the refund path can target.

POST /v1/orders
external_reference_id
metadata
line_items[].sku

Refunds target lines, so the arithmetic is not yours to repeat.

Refunds on pre-cutover orders stay with the old processor. Refunds issued here after cutover look like this: name the line and the quantity, and let tax follow automatically rather than recomputing it in your own code and hoping it matches.

curl

curl -X POST https://api.withflintpay.com/v1/refunds \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Idempotency-Key: refund-100000042-anchors" \
  -d '{
    "order_id": "ord_1kmn0aExample",
    "external_reference_id": "creditmemo-100000031",
    "reason": "requested_by_customer",
    "line_items": [
      { "order_line_item_id": "oli_2pqr7bExample",
        "quantity": 3,
        "tax_refund_mode": "automatic" }
    ]
  }'

The credit memo number rides along as the refund's own external reference.

201 Created

{
  "data": {
    "refund_id": "ref_1kmn0aExample",
    "order_id": "ord_1kmn0aExample",
    "external_reference_id": "creditmemo-100000031",
    "status": "succeeded",
    "amount_money": { "amount": 7776, "currency": "USD" },
    "line_item_allocations": [
      { "order_line_item_id": "oli_2pqr7bExample",
        "quantity": 3,
        "amount_money": { "amount": 7200, "currency": "USD" },
        "tax_money":    { "amount": 576,  "currency": "USD" } }
    ]
  }
}

Goods and tax are allocated per line. You asked for a quantity, not an amount.

POST /v1/refunds
line_items[].order_line_item_id
tax_refund_mode
refund_status

GET the order afterwards

{
  "data": {
    "order_id": "ord_1kmn0aExample",
    "external_reference_id": "100000042",
    "payment_status": "paid",
    "refund_status": "partially_refunded",
    "line_items": [
      { "order_line_item_id": "oli_1kmn0aExample",
        "quantity": 1, "refunded_quantity": 0 },
      { "order_line_item_id": "oli_2pqr7bExample",
        "quantity": 3, "refunded_quantity": 3 }
    ],
    "settlement_amounts": {
      "paid_money": { "amount": 9612, "currency": "USD" }
    }
  }
}

The order knows what was returned, per line and in total. Nothing had to be reconstructed from a settlement file.

The state changes arrive as events.

Terminal refund states arrive as an update carrying the new status rather than as a separately named event, which is a small thing that costs people an afternoon.

POST your endpoint

{
  "webhook_event_id": "whev_1kmn0aExample",
  "event_type": "refund.updated",
  "payload_version": 1,
  "mode": "test",
  "merchant_id": "mer_1kmn0aExample",
  "created_at": "2026-07-25T14:00:00Z",
  "data": {
    "refund_id": "ref_1kmn0aExample",
    "order_id": "ord_1kmn0aExample",
    "external_reference_id": "creditmemo-100000031",
    "status": "succeeded",
    "amount_money": { "amount": 7776, "currency": "USD" }
  }
}

Your external reference is in the payload, so the listener can find the Magento record without a lookup table.

order.paid
order.partially_paid
order.refunded
refund.created
refund.updated
refund.failed

Every order carries your Magento increment id as a first-class field.

external_reference_id

Arbitrary key-value data rides along, so entity and store ids survive the move.

metadata

Refunds name a line and a quantity rather than an amount you computed.

line_items[].order_line_item_id

Tax on a returned line is allocated for you rather than recomputed by you.

tax_refund_mode

Stored cards are collected from the buyer. There is no import parameter.

POST /v1/payment-methods

reviewed 2026-07-25 against the published API

08Limits

What Flint does not do.

Flint is not a Magento replacement. No storefront, no themes, no CMS, no product pages, no merchandising, no extension marketplace. If what you need is a store, this is the wrong category of product and no amount of API surface changes that.

There is no bulk import. Catalog, customers, and order history are your own code against the public API, resource by resource. There is no migration tool, no CSV importer, and no Magento connector. For a large catalog that is real work, and it is work you would be doing rather than buying.

There is no way to bring stored cards. A gateway token is not portable, and that applies to Flint too. Every buyer with a card on file re-enters it.

No net terms. ACH bank debit is supported, in one shape: a one-time, on-session debit in USD, paid while the buyer is present. What does not exist is invoiced net-30 with credit limits or accounts receivable, so a B2B store settling most of its volume on terms is not served by this today.

Flint is not a payment processor. Stripe processes every card, and Flint provisions and operates the processing account. You cannot attach a Stripe account you already have, and Flint inherits Stripe underwriting: if Stripe declined your business, Flint cannot approve it.

No PHP SDK. The clients are a Node SDK and a CLI, which for a Magento shop is a real cost worth pricing in early. Everything else talks to documented REST, which is stable, and in PHP the requests are yours to hand-roll.

09The other verdict

When upgrading in place is the right answer.

Which, for a working store on a supported version, is most of the time.

If your store works, your extensions are maintained, and you are on 2.4.7 or newer, you have years of standard support ahead of you and no forcing function at all. Upgrading annually is cheaper than any migration, and it carries neither the vault problem nor the cutover overlap. Do that, and come back to this question when something other than a support date is driving it.

If you need a storefront with themes, merchandising, faceted search, and an extension ecosystem, buy a platform. Adobe's licensed editions, Shopify, and the open-source headless engines all sell that, and Flint does not.

The reason to leave is not that Magento is bad software. It is that your version is aging out and the upgrade is no longer worth what it costs you, or that what you are building stopped being a store some time ago. Those are different problems, and only the second one points at an API.

10Sources

Check the claims.

Every date and every statement about Adobe's products on this page comes from one of these. If one has gone stale, tell us and we will date the correction.

Per-version standard and extended support dates for every 2.4.x release. Software lifecycle policy
experienceleague.adobe.com
Extended support patches are for Adobe Commerce customers only, not Open Source. Release policy
experienceleague.adobe.com
Release dates and the latest security patch for each supported line. Released versions
experienceleague.adobe.com
What the vault stores: a gateway token and a public hash, never card data. Vault payment token
developer.adobe.com
How a payment method becomes a vaulted token in the first place. Vault integration overview
developer.adobe.com
The B2B feature set, and that it is an Adobe Commerce module. Adobe Commerce B2B
experienceleague.adobe.com
Purchase order flow, for the B2B scoping note in section 06. Purchase orders for companies
experienceleague.adobe.com
Adobe Commerce as a Cloud Service, the SaaS line introduced in 2025. Adobe Commerce as a Cloud Service
experienceleague.adobe.com

last reviewed 2026-07-25 · corrections: support@withflintpay.com

FAQ

Questions worth asking first.

When does Magento Open Source stop getting security patches?

At the end of standard support for your version, not the end of extended support. Adobe's release policy states that extended support security patches are available to Adobe Commerce customers only and are not available for the Magento Open Source code base. So 2.4.6 Open Source stops receiving patches on August 11, 2026, while an Adobe Commerce store on the same version has extended support into August 2027. Open Source stores on 2.4.4 and 2.4.5 are already past their standard support dates.

Can I migrate my saved credit cards off Magento?

Not by exporting them. Magento's vault stores a gateway token and a public hash, never card data, and that token is only meaningful to the gateway that issued it. Moving stored cards means a processor-to-processor transfer that your old and new providers both have to agree to and staff, and for network tokens the card networks may be involved too. It is a commercial negotiation with a technical tail, not a data export, and it belongs at the start of your timeline rather than the end.

What happens to refunds for orders placed before the cutover?

They have to be issued where the money was captured. A refund needs the original charge, and the new platform does not have it, so you keep the old gateway account open and reachable for the length of your refund and chargeback window. Plan for both systems to be live at once for that period, and decide up front which one your support team opens first.

Is Magento Open Source going away?

No. Adobe continues to ship Magento Open Source releases on an annual cadence, with 2.4.9 released on May 12, 2026 and standard support running to May 2029. What changed is the shape of the support underneath it: extended support is a paid-tier benefit, so the free edition's usable life is the standard support window rather than the longer date most migration guides quote.

Does Magento Open Source include the B2B features?

No. Company accounts, negotiable quotes, requisition lists, and shared catalogs are part of the Adobe Commerce B2B module, not Open Source. Open Source stores that need them run third-party extensions or custom code. Worth knowing before a migration plan assumes those features are portable, because in most Open Source stores the equivalent is bespoke and moves like any other custom code.

Can Flint replace Magento?

No, and it is the wrong shape for that. Flint is a commerce and payments API with no storefront, no themes, no CMS, and no merchandising tools. It covers orders, catalog, inventory, checkout, and payments. If you are replatforming a store you need a store. Flint is the layer underneath whatever head you choose, useful when you are building custom rather than buying a platform.

Can Flint import my Magento catalog and order history?

Not today. There are no bulk import endpoints, so a catalog or order backfill is your own code against the public API, one resource at a time. What Flint does carry is the identifiers: orders and refunds take an external_reference_id plus arbitrary metadata, so your Magento increment id and entity id can travel with every record and your reporting keeps working across the boundary.

We are on 2.4.4 or 2.4.5 Open Source. How bad is that?

You are running unpatched. Standard support for 2.4.4 ended April 12, 2025 and for 2.4.5 on August 12, 2025, and the extended dates that appear next to those versions in most tables apply only to Adobe Commerce customers. That does not make it an emergency in the sense that anything has stopped working, but it does mean new vulnerabilities in your version are not being fixed for you, and any migration timeline should be measured against that rather than against a future date.

Start

Ten minutes, no card required.

Free sandbox keys. Create an order with your Magento increment id on it, pay it with a test card, then refund one line and watch the totals move.

npm install @flintpay/node

brew install flintpay/tap/flint

Test keys run against an isolated sandbox on the same host as live. Test mode is a property of the key, not a flag on the request, so there is no environment switch to forget.

Get free API keys

Then read these three.

Refunds, line by lineQuantities, tax allocation, and what partial refunds do to the order.
Orders API referenceEvery field on the order, including the external reference and metadata.
The commerce APICatalog, inventory, and orders on one API, for when the storefront is yours.

Your catalog will migrate. Your saved cards will not.

Four things people mean by Magento.

Extended support is not for you.

Your vault holds tokens that belong to your gateway.

What Flint can and cannot take.

Four problems that only exist on the day you switch.

Refunds for orders you already captured.

Authorizations that are open on the day you switch.

Every customer with a card on file.

One accounting month, two settlement sources.

What the alternatives cost.

Five questions worth answering first.

How many active cards are in your vault?

Do you have recurring or scheduled orders?

Is your storefront already being rebuilt?

Does anything about your commerce not fit a store?

Who is doing the work?

What the order layer looks like underneath.

Refunds target lines, so the arithmetic is not yours to repeat.

The state changes arrive as events.

What Flint does not do.

When upgrading in place is the right answer.

Check the claims.

Questions worth asking first.

Ten minutes, no card required.

Then read these three.