Cafe24 preparation should begin with scope separation. A Cafe24 account may include a default Store, localized Stores, language-specific Categories and content, Product visibility rules, several option-selection models, variant-level inventory, Customer levels, and operational apps or outside systems. These relationships can be hidden when preparation begins with a single Product or Order export.
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 exact Cafe24 account, default Store, localized Stores, domains, active languages, currencies, regional operating context, administrator roles, and the teams responsible for catalog, Customers, Orders, content, privacy, tax, fulfillment, and integrations. Determine which localized Store information inherits from the default Store and which information has been edited independently.
| 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
Cafe24 supports several Product option models. Preset or multiple-option selection can create variants from option combinations. Independent selection can add option values individually, while custom selection can capture required or optional buyer choices and may use Product-level rather than variant-level inventory. Custom text and file attachment inputs can also collect purchase-specific information.
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 |
|---|---|---|---|
| Preset or multiple-option Product | 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. |
| Custom-selection Product | Record input rules, required state, pricing effect, and Product-level stock behavior | Product and Order samples | Buyer-specific choices have a defined owner. |
| 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. |
Do not normalize option labels or merge variant codes until the business owner confirms that the records have the same meaning across Stores and Orders.
Prepare Categories, Display Rules, Navigation, and SEO Paths
Cafe24 Categories can be nested, assigned Store-specific translated names, control display and sale context, use different Product layout sections, and restrict access by account or Customer level. Prepare Category records and storefront navigation as related but separate evidence.
| 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 | Account-only, Customer-level, administrator-only, adult or IP restriction examples | 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. |
Sensitive Customer fields should be limited to what is required for the agreed scope and handled according to the business’s privacy and access controls.
Prepare Orders, Payments, Refunds, and Fulfillment Context
Cafe24 Order preparation should cover Orders from different Stores, languages, Customer states, Product option models, payment methods, shipping methods, tax contexts, discounts, points, refunds, cancellations, exchanges, returns, and fulfillment states. The All Orders area can be used to locate and export Orders by period and business scenario; save the filters and date range used for each file.
| 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 live target payment gateways, tax, shipping, or fulfillment rules.
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
Create a dependency register for Cafe24 apps, API integrations, webhooks, marketplaces, payment services, shipping and logistics providers, ERP, accounting, CRM, warehouse, analytics, marketing, reviews, and custom code. Record which Store and language each dependency affects.
| 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, apps, and integration fields. Save filter criteria, Store and language scope, selected columns, date ranges, and checksums. Keep original exports unchanged and use working copies for cleanup.
| 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, combination variant, independent option, custom-selection Product, 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. |
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, source evidence, integrations, representative records, and change control are complete, migration configuration can proceed from documented Cafe24 behavior rather than a flat record count.
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?
Combination, independent, and custom selection can produce different Product, inventory, and Order behavior. A generic option list does not preserve those differences.
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.