Cafe24 preparation depends on two distinctions: which Store owns a localized value, and which option model owns the purchased item and its stock. Establish both from Source evidence before the destination is populated, especially when the same Product appears across several localized Stores.
Start by mapping the actual Source storefronts to the intended Cafe24 default and localized Stores. The destination may use language-specific Categories and content, display rules, different option-selection models, Customer levels and connected apps. Confirm the enabled Store design and agreed data scope; the presence of a native capability does not establish its availability or migration coverage.
The objective is to create source evidence that shows which Store, language, Customer level, Product option model, and external system owns each important behavior. Every major area should define the action, owner, evidence, and ready condition before migration configuration is finalized.
Establish Access and Define the Cafe24 Store Scope
Record the intended Cafe24 account, default and localized Store identifiers, domains, active languages, currencies and regional owners, then map the Source contexts to them. If Cafe24 is the Source, preserve its native Shop identifiers and access evidence; otherwise collect equivalent relationships from the actual Source. Determine inheritance field by field using representative Product, Category, content and setting comparisons rather than assuming every localized value follows the default Store.
| Action | Owner | Evidence | Ready condition |
|---|---|---|---|
| List default and localized Stores | Platform administrator | Store list, domains, languages, currencies, status | Every included Store has a documented role. |
| Confirm source access | Access owner | Administrator access, export permissions, technical contact | Required source evidence can be collected. |
| Record inheritance and localization | Content and catalog owners | Product, Category, content, and settings comparison | Shared and localized information are distinguishable. |
| Identify regional responsibilities | Legal, finance, and operations owners | Tax, privacy, shipping, payment, and fulfillment ownership note | Regional settings have named owners. |
| Inventory active apps and integrations | Systems owner | App list, purpose, data objects, status | Non-core data and workflows are visible. |
| Start a change log | Project owner | Dated catalog, Customer, Order, URL, and configuration changes | The evidence set will remain current. |
Prepare Products, Options, Variants, and Inventory
Document the actual Cafe24 option type rather than relying on a generic label. Combined options, with complete or separate selection, represent stock-bearing combinations. Independent selection adds chosen option items separately and can have item-level stock. Product-linked options can distinguish required and optional selections, but use Product-level stock rather than stock for every combination. Text and file inputs are a separate layer of purchase-specific evidence.
Prepare Product number, Product code, custom Product code, name, status, display and sale scope by Store, Category assignments, price, tax, images, descriptions, option model, option values, variant code, custom variant code, stock settings, stock-deduction basis, extra charges, custom text or file input, and external identifiers.
| Product pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Combined-option Product, with complete or separate selection | Record option names, values, combinations, variant codes, price, stock, display and sale state | Product and inventory export samples | Combination-level meaning is complete. |
| Independent-selection Product | Record required and optional values, individual purchase behavior, and stock granularity | Product page and Order-line examples | Individually selected options are not mistaken for one variant. |
| Product-linked selection, including required or optional choices | Record choice rules, required state, pricing effect and Product-level stock behavior | Product and Order samples | Selection behavior is distinguished from combined variants and buyer text/file inputs. |
| Custom text or file attachment | Record field purpose, required state, file retention owner, and Order relationship | Product settings and historical Orders | Purchase-specific input is represented in the source evidence. |
| Localized Product | Record default and localized titles, descriptions, prices, display and sale settings | Cross-Store Product comparison | Localization and Store scope are explicit. |
| Inventory exception | Record stock type, deduction basis, negative or out-of-stock behavior, and minimum level | Inventory export and exception list | Availability meaning is documented. |
Keep Product numbers/codes, variant codes, custom codes and the relevant Store identifier in the evidence. Confirm how a selected choice affects item quantity, price and stock with an Order example for each option model. Similar names or translated labels do not prove that codes identify the same record; resolve proposed merges with the business owner before normalizing them.
Prepare Categories, Display Rules, Navigation, and SEO Paths
Prepare the Source Category hierarchy, localized labels, Product assignments and actual display, sale and access rules separately from menus and theme navigation. Identify which intended Cafe24 Store owns each Category and layout placement. Where the Source has buyer or other restrictions, record the responsible rule and confirm its destination implementation instead of assuming that Category data alone transfers access control.
| Discovery area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Category hierarchy | Catalog owner | Parent-child tree, status, Product assignments | Every retained Category has a known parent and purpose. |
| Localized Category information | Content owner | Default and localized names, descriptions, routes | Translation scope is documented. |
| Product layout sections | Merchandising owner | Products, Recommended Products, and New Products assignments | Display placement is not inferred from Category membership alone. |
| Access restrictions | Customer or B2B owner | Actual Source account, Customer-level, administrator, adult or IP rules where present, with destination implementation owner | Restricted discovery has a named rule owner. |
| Menus and theme navigation | Storefront owner | Navigation map, screenshots, linked Categories and pages | Presentation paths are separated from Category data. |
| SEO routes | SEO owner | Category and Product URLs, metadata, priority routes, redirects | High-value paths have a disposition. |
Prepare Customers, Customer Levels, Accounts, and Consent Evidence
Cafe24 can manage registered Customers, shoppers without accounts, Customers with purchase history, Customer levels, signup fields, deleted-account records, and automated communications. Prepare Customer identity and segmentation by actual business use.
Record Customer number or identifier, name, email, login or account state, language or Store, addresses, signup fields, Customer level, purchase-history relationship, consent and communication state, tax or business information, points or credit context where used, and external identifiers.
| Customer pattern | Preparation action | Evidence | Ready condition |
|---|---|---|---|
| Registered Customer | Record identity, Store, account state, addresses, and level | Customer and Order samples | Account ownership is clear. |
| Guest buyer | Record Order identity without assuming a registered account | Guest Order set | Guest history remains distinct. |
| Customer-level member | Record level meaning, benefits, discounts, access rules, and owner | Customer-level rule matrix | Segmentation has documented business meaning. |
| Custom signup fields | Classify each field by purpose, sensitivity, and downstream use | Field dictionary | Required account context has a disposition. |
| Deleted or inactive account | Record retention reason and related Order history | Exception register | Historical identity is handled deliberately. |
| External-system Customer | Record CRM, ERP, payment, fulfillment, or support identifiers | Integration references | Lookup keys remain traceable. |
Prepare Customer-level membership and benefits separately from account access. The exact Source-to-Target path and identity systems determine usable password-verification continuity or the reset, activation or first-login plan. Assign the customer communication and restrict sensitive fields to the agreed scope and the business’s actual privacy/access controls.
Prepare Orders, Payments, Refunds, and Fulfillment Context
Collect historical Order evidence by Store, language, date range and business scenario. Include Customer states, option models, payment and shipping methods, tax, discounts, points, refunds, cancellations, exchanges, returns and fulfillment. Retain the selected fields, filters and capture date with each file; a count without its extraction scope does not establish coverage.
| Order area | Action | Evidence | Ready condition |
|---|---|---|---|
| Store and language | Include Store, locale, currency, and Customer context | Cross-Store Order samples | Every Order can be interpreted in its original Store context. |
| Product selections | Include option values, variant codes, custom input, quantity, price, and Product text | Representative Order lines | Purchased configuration remains understandable. |
| Status and fulfillment | Record status labels, payment state, shipping state, tracking, cancellation, return, and exchange context | Status dictionary and Orders | Historical workflow can be interpreted. |
| Totals | Identify Product amount, option charge, tax, shipping, discount, points, refund, and fee components | Total-component samples | Financial context is complete. |
| Addresses | Separate Customer addresses from Order-time billing and shipping snapshots | Customer and Order examples | Current account data is not conflated with history. |
| External references | Record payment, logistics, marketplace, ERP, accounting, and support identifiers | Integration-sensitive Orders | Cross-system lookup requirements are documented. |
Historical payment and shipping records describe past transactions. They do not configure future gateways, tax, delivery or fulfillment, and they do not authorize another charge, refund, notification or shipment. Identify the live systems and transition owners separately from the historical evidence.
Prepare Content, Themes, Localized Pages, and Media
Prepare pages, policies, Product and Category content, home-page sections, banners, themes, mobile presentation, forms, images, downloadable files, metadata, internal links, and localized versions. Cafe24 themes can contain configured content and source-code customizations, so the theme owner should identify any data or business logic embedded in templates.
| Content area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Pages and policies | Content or legal owner | Page inventory, Store, language, status, route | Retain, rebuild, merge, or exclude decisions are documented. |
| Product and Category content | Catalog owner | Default and localized content exports or samples | Content can be matched to the correct record and Store. |
| Theme sections | Theme owner | Theme backup or source record, custom sections, screenshots | Presentation-owned content is visible. |
| Media | Content owner | Original files, paths, Product or page relationships | Source assets are available. |
| SEO metadata and routes | SEO owner | Titles, descriptions, URLs, canonical expectations, internal links | Search context accompanies content evidence. |
Inventory Apps, APIs, Webhooks, and External Systems
Inventory the apps and API/webhook consumers intended for the Cafe24 destination, together with the actual Source systems that provide their evidence. Include marketplaces, payment/logistics, ERP, accounting, CRM, warehouse, analytics, marketing, reviews and custom code. Record the affected Shop, locale, resources, authorization owner and required permission scopes. An authorized app is not proof that it can retrieve every required resource or localized Store.
| Dependency field | Required detail | Ready condition |
|---|---|---|
| Owner and purpose | Business and technical owners, workflow supported | Responsibility is explicit. |
| Store scope | Default Store, localized Store, or all Stores | Regional ownership is known. |
| Data objects | Products, variants, stock, Customers, Orders, content, or settings | Affected evidence is identified. |
| Direction and timing | Read, write, two-way, scheduled, event-driven, or manual | Source authority is documented. |
| Identifiers | Product code, variant code, Customer ID, Order number, external key | Lookup dependencies are preserved. |
| Transition decision | Reconnect, rebuild, retire, replace, or review | Continuity is not assumed. |
Prepare Exports, Media, Backups, and Change Control
Create dated Source archives for Products, options, variants, inventory, Categories, Customers, Orders, content and dependencies. Retain Store/language scope, selected fields, filters, date ranges and checksums. With Cafe24 API evidence, an omitted Shop context can return the default first Shop; require explicit coverage evidence for every included localized Store. Keep originals unchanged, and record available backup or provider recovery coverage rather than promising a database restore from hosted exports.
| Evidence set | Required contents | Ready condition |
|---|---|---|
| Product and inventory files | Product, option, variant, stock, Store, and Category fields | Catalog and availability evidence is complete. |
| Customer and Order files | Store, account state, levels, addresses, Orders, statuses, totals, and external IDs | Historical relationships are attributable. |
| Content and theme archive | Pages, localized content, media, theme backup or source record | Presentation and source assets are available. |
| Dependency evidence | App list, API or webhook notes, external-system fields | Non-core ownership is documented. |
| Backup and support note | Available account backups, export archive, media archive, technical contacts | Source evidence can be recovered. |
| Change log | New and edited Products, Customers, Orders, URLs, apps, and settings | Later source changes can be reconciled. |
Select Representative Migration Test Records
| Sample group | Include | Preparation purpose |
|---|---|---|
| Products | Simple Product, combined-option variant, independent option, Product-linked selection, file or text input, localized Product, stock exception | Expose distinct catalog models. |
| Customers | Registered, guest, Customer-level member, custom-field account, deleted or inactive exception, external-ID Customer | Represent identity and segmentation differences. |
| Orders | Different Stores, option models, payment and shipping states, refund, return or exchange, discount or points, external reference | Preserve historical operating context. |
| Discovery and content | Localized Category, restricted Category, Product layout placement, theme page, priority URL | Prepare Storefront and route relationships. |
| Integrations | Product, Customer, or Order touched by an app, API, webhook, or outside system | Include cross-system identifiers. |
Write a short source expectation for each sample. It should identify the Store, language, relationship, fields, linked files, and identifiers that make the record representative.
Complete the Cafe24 Readiness Gate
| Final gate | Ready condition |
|---|---|
| Store scope | Default and localized Stores, languages, domains, inheritance, and regional owners are documented. |
| Products | Option models, variants, codes, inventory, Store scope, content, and external IDs are represented. |
| Discovery | Categories, layout sections, restrictions, navigation, localized routes, and SEO inputs are prepared. |
| Customers | Registered, guest, level, custom-field, deleted, and external-ID cases are understood. |
| Orders | Store, language, Product selections, statuses, fulfillment, totals, refunds, and external references are interpretable. |
| Content | Pages, themes, media, localization, metadata, and routes are documented. |
| Dependencies | Apps, APIs, webhooks, marketplaces, and outside systems have owners and dispositions. |
| Inputs | Exports, filter criteria, assets, backups, checksums, contacts, and change log are available. |
| Samples | Representative migration records cover ordinary and complex source patterns. |
The gate is complete when the Source evidence and intended Cafe24 relationships are traceable, destination prerequisites have owners and critical gaps are resolved, excluded or held before execution. Record an accepted boundary and impact for any noncritical exception; an owner and due date alone do not make a missing Store, stock or integration decision ready.
Conclusion
Cafe24 preparation should preserve Store, language, Product option, Customer-level, inventory, and Order context before records are moved. Those relationships determine whether exported data can still be interpreted outside the source account.
When access, localized scope, option and stock evidence, integration ownership and representative records are ready, migration configuration can proceed from documented Source relationships and intended Cafe24 behavior. A flat record count cannot supply that context.
Common Questions
Should default and localized Cafe24 Stores be prepared separately?
Yes. Record which information is inherited from the default Store and which Product, Category, content, price, visibility, or route values have been localized.
Why must Cafe24 option-selection types be documented?
Combined, independent and Product-linked selection can create different purchased-item, quantity and stock behavior. Prepare a Product and historical Order example for each type used, plus text/file inputs where relevant. A generic option list does not preserve those distinctions.
Which inventory fields are most important?
Prepare Product and variant codes, tracking state, available stock, deduction basis, minimum level, display and sale state, extra charges, and the system that owns current quantities.
How should Customer levels be prepared?
Document membership, business purpose, discounts, access restrictions, benefits, affected Stores, and the owner who can explain each level.
Which Orders should be selected as samples?
Include different Stores and languages, option models, payment and fulfillment states, discounts or points, refunds, returns or exchanges, guest and registered Customers, and external references.
How should source changes after export be handled?
Maintain a dated log for Products, variants, stock, Customers, Orders, URLs, apps, and regional settings so changes can be reconciled with the prepared evidence set.
Does a default-Store export cover every localized Cafe24 Store?
It does not establish that coverage by itself. Record the Shop or Store scope, fields and filters for each evidence set, then compare the required localized records. Cafe24 API retrieval without an explicit Shop context can return the default first Shop. Prepare attributable evidence for every included localized Store.
Do identical Product names justify merging codes across Stores?
No. Keep the Product and variant identifiers with their Store context, then confirm whether they refer to a shared record, a localized representation or a distinct offer. Preserve external-system keys and historical Order links before deciding on a merge. Names and translated labels alone are insufficient identity evidence.