Migrating from WP All Import

Super Speedy Imports can read saved WP All Import jobs and turn them into reviewable Super Speedy Imports configurations. It copies or converts the source, translates the settings it can represent safely, and reports anything that needs a decision. Creating the configuration does not run an import.

Available since 2.87.

Migrate a saved WP All Import job

1. Keep WP All Import installed while you migrate. Super Speedy Imports reads its saved import and file-history tables directly. Removing WP All Import after you have migrated is fine and does not block the migrated imports.
2. Open Super Speedy Imports > Migration Tools in wp-admin.
3. Find the WP All Import migration table. It lists the saved jobs SSI can discover, their targets, source files and migration status.
4. Select the jobs you want to copy and click Migrate selected imports.
5. Open the resulting SSI configuration and check its mappings and options.
6. Use Review differences to see what matched, what SSI represents differently and what still needs attention.
7. Use Preview when the job is marked safe to preview. This creates draft content from the first source item so you can inspect the result without running the full import.
8. Discard the preview when you’ve checked it, then run the import when you’re satisfied with the configuration.

Migrating the same WP All Import job again doesn’t create uncontrolled duplicates. Select Refresh existing SSI migrations when you deliberately want SSI to rebuild an earlier migration from the current WP All Import configuration.

What SSI translates

Where the source job and destination are supported, SSI translates:

• post title, content, excerpt, slug and date mappings
• WooCommerce SKU, regular price, sale price, stock, weight and dimensions
• custom fields, including WP All Import’s “only these custom fields” update setting
• product attributes, their taxonomy slugs and whether they are used for variations
• taxonomy mappings, hierarchy mode and hierarchy separator
• the unique identifier and duplicate-matching settings, including matching on the WordPress Post ID, on the slug, or on the title column the job actually matches on
• update-only behaviour, and what the job does with items missing from the feed (see below)
• field and decimal separators

SSI needs the original readable CSV/text source for CSV jobs, not only WP All Import’s internal cache. If that original is missing, restore the source file named in the migration message. SSI copies a readable local source into its protected imports directory. For XML jobs, the XML remains the canonical source and SSI creates a rebuildable CSV working copy. A supported remote source can become a recurring source which SSI fetches and validates when the import runs.

Items missing from the feed

WP All Import decides what happens to items missing from the feed with several settings. SSI reads all of them and configures the migrated import to match:

Review differences states which of these happened and names anything WP All Import does that SSI has no equivalent for. One example: a WP All Import job can act on every item of its post type missing from the feed, while SSI only ever removes items this import has loaded, so it affects fewer items than the source job.

For update-only jobs, SSI translates the fields that the original job permits it to update. Review those mappings against the original job’s enabled fields; do not assume every source column should be written.

What needs review

SSI reports a difference instead of guessing when the source behaviour can’t be represented safely. Common examples include:

• arbitrary PHP expressions
• featured-image or gallery mappings
• a unique identifier built from an expression rather than one column
• an attribute name taken from the feed itself
• a field name that could match more than one CSV header after punctuation is removed
• orders, refunds or an unsupported post type

The browser comparison displays differences. Some unsupported behaviour needs manual configuration or a different workflow; don’t assume every difference can be resolved by clicking through the GUI.

A migrated import that still carries something that could not be translated does not run. Preview & Run, wp ssi and a schedule all refuse it with a message naming what is left, so a half-translated job never reaches its delete-missing step. Map the affected fields yourself to clear it.

The migration tool never executes WP All Import’s PHP. In Super Speedy Imports, a job whose mappings used PHP arrives with your WP All Import functions file (wp-content/uploads/wpallimport/functions.php) and the exact field expressions copied into the import’s Custom Functions editor, all commented out. Uncomment and adapt what you need as described below; the affected fields are still yours to map.

Functions SSI converts without PHP

A direct WP All Import field reference such as {sku[1]} becomes an ordinary CSV Field mapping. You don’t need to convert it into PHP.

SSI can also translate nested calls to these pure functions into declarative mappings:

• trim
• strtolower
• strtoupper
• ucwords
• strip_tags
• intval
• floatval
• abs
• round (with precision from 0 to 10)
• html_entity_decode

The innermost argument must resolve to a single source column. SSI stores these as a fixed transform pipeline, not as executable PHP. Calls outside this list are reported for review.

Use native mappings where possible

Before writing PHP, check whether one of SSI’s mapping methods expresses the result directly:

• CSV Field maps one source column to the destination.
• Value sets the same value for every row. An empty Value clears the destination field.
• Editor combines literal text with {Column Name} tokens. For example, {product_name} by {brand_name} joins two columns without PHP.
• PHP runs a callable once per row and is available in Super Speedy Imports.

Native mappings are easier to inspect and don’t depend on evaluating user-authored PHP.

Convert unsupported custom PHP

When the migration report identifies an unsupported PHP expression, recreate only that logic. The commented copy in Custom Functions is the starting point. SSI has two PHP areas:

1. Custom Functions contains shared named helper functions. Paste function declarations here without the opening <?php tag.
2. A field’s PHP mapping contains a callable closure which receives the current CSV row and the header map, then returns the value for that field.

The field callable has this form:

return function($data, $h) {
    return $data[$h['column_name']];
};

• $data is the current CSV row.
• $h maps each CSV header to its position in that row.
• $data[$h['sku']] reads the sku column for the current row.

For example, this WP All Import expression calls a helper with two source values:

[zero_price({product_price_old[1]}, {search_price[1]})]

Define zero_price() in Custom Functions, then use this field mapping:

return function($data, $h) {
    return zero_price(
        $data[$h['product_price_old']],
        $data[$h['search_price']]
    );
};

An error in custom PHP stops the import and reports the error. Test the migrated logic with Preview before running it across the full source.

ChatGPT prompt for converting a PHP function

Copy the prompt below into ChatGPT, then replace the three labelled placeholders with the exact code, mapping expression and CSV headers from your import.

I need to convert custom PHP from WP All Import to Super Speedy Imports.

Super Speedy Imports has two places for PHP:

1. The Custom Functions editor contains named PHP function declarations. It must
   not include an opening <?php tag.
2. Each field's PHP mapping must return one callable with this exact shape:

   return function($data, $h) {
       return $value;
   };

$data is the current CSV row. $h maps an exact CSV header to that column's
position. Read a column named sku as $data[$h['sku']].

Convert the material I provide below while preserving its behaviour.

Rules:
- Use only the CSV headers I provide. Do not invent or normalise a header name.
- Put reusable named functions in the Custom Functions output.
- Put the row-specific call in the Field PHP mapping output.
- Replace WP All Import references such as {sku[1]} with $data[$h['sku']].
- Do not include an opening <?php tag.
- Do not rename a function unless PHP requires it. If you rename one, update every call.
- Do not silently remove WordPress or WooCommerce calls, globals, database access,
  file access, remote requests, hooks or other side effects. Flag each one for review.
- If the original code depends on WP All Import variables, APIs or execution order,
  explain the dependency and stop instead of guessing a replacement.
- If any required header, function or context is missing, list it under Questions
  instead of inventing it.
- Return code I can paste, followed by a short explanation and three example input/
  expected-output checks. Do not wrap the PHP in Markdown unless I ask.

Output these sections:
A. Custom Functions
B. Field PHP mapping
C. Assumptions and risks
D. Questions
E. Example checks

WP ALL IMPORT FUNCTION EDITOR CODE:
[PASTE THE ORIGINAL FUNCTION DECLARATIONS HERE]

WP ALL IMPORT FIELD MAPPING OR EXPRESSION:
[PASTE THE ORIGINAL FIELD MAPPING HERE]

EXACT CSV HEADERS:
[PASTE THE COMPLETE HEADER ROW HERE]

Check ChatGPT’s output before saving it. Confirm that every $h['...'] value exactly matches a real header, every called helper appears in Custom Functions, and any WordPress or WooCommerce side effects still make sense in SSI’s import process.

Check the rest of the migrated configuration

• Unique identifier: confirm that WP All Import’s unique key became the intended unique item identifier. SKU is common for products, but it isn’t the right choice for every source.
• Custom fields: inspect the mappings described in Mapping CSV columns to custom postmeta.
• Categories: check the separator and whether Assign every category level matches the source job. See Mapping hierarchical and multi-path taxonomies.
• Images: review featured-image and gallery settings manually when the migration report flags them.
• Delete missing: check this setting carefully before running against live content.

For logic that changes whole rows or adds new import stages, see Creating custom templates.

Command-line migration

The same migration and comparison services are available through WP-CLI:

wp ssi migrate-wpai list
wp ssi migrate-wpai all
wp ssi migrate-wpai 12,34
wp ssi migrate-wpai 12 --refresh
wp ssi compare-wpai 12 56
wp ssi migration-status 56

Replace 12 with the WP All Import job ID and 56 with the migrated SSI import ID. These commands create or inspect configurations; they don’t run the migrated import.

Further reading

Related products

Super Speedy ImportsEasy to use. Built for speed.

Written for Super Speedy Imports 3.40.0.