Importing and exporting settings in Aimogen is meant to solve one very specific problem: moving configuration reliably between environments without copying databases or manually recreating complex setups. This includes generators, limits, chatbots, workflows, and global behavior, while keeping execution safe and predictable.
Aimogen itself does not bundle a custom export UI. Instead, the recommended and supported approach is to use the CodeRevolution Configuration Import/Export Helper Plugin, which is built specifically for CodeRevolution plugins and understands how their settings are stored.
Aimogen configuration lives in multiple places: plugin options, custom post types, metadata, and structured settings arrays. Exporting these correctly requires awareness of how the plugin stores data. This is exactly what the helper plugin does. It exports configuration intentionally, instead of cloning the entire database and dragging runtime data along with it.
The goal is to move behavior, not history.
The typical use case is moving from local or staging to production, or synchronizing multiple environments that must behave identically. You export settings from the source site, import them into the target site, then apply environment-specific adjustments such as API keys.
This workflow avoids accidental leakage of logs, usage data, or test content.
To export Aimogen settings, you first install and activate the Configuration Import/Export Helper plugin on the source site. Once active, it provides an export interface where you can select plugin configurations. Aimogen appears as a selectable plugin. When exporting, you should include global settings, generators, chatbots, workflows, limits, and schedules.
API keys should be handled carefully. While they may technically be exportable, best practice is not to move live API keys between environments. Production, staging, and development should each use their own keys. This protects billing and avoids accidental cross-environment usage.
The export process produces a configuration file that represents Aimogen’s setup at that moment. This file does not contain generated posts, logs, execution history, or provider billing data. It contains configuration only.
On the target environment, you install Aimogen first, then install the same helper plugin, and import the exported configuration file. Aimogen recreates its settings, rules, chatbots, workflows, and limits exactly as defined on the source site.
After import, API keys must be reviewed and entered manually in Settings → API Keys, because provider connections are environment-specific by design.
Scheduled rules deserve special attention. Imported schedules are recreated, but they will only run if WordPress cron is functioning correctly on the target site. On production, this usually means using a real server cron instead of relying on traffic-based WP-Cron. After import, scheduled generators should be reviewed and triggered manually once to confirm behavior.
Embeddings should usually be regenerated rather than migrated. Embeddings depend heavily on content and language. If the target environment does not have identical content, re-embedding ensures accuracy. While index mappings may migrate, vector data itself should be treated as environment-specific unless you have a strong reason to preserve it.
Chatbots migrate cleanly as configuration. Personas, prompts, workflows, placement rules, and limits are restored exactly. After import, chatbots should be tested visually and functionally to confirm that theme CSS, language context, and embeddings align with the new environment.
Usage limits, permissions, and role-based restrictions migrate as configuration as well. This is important for SaaS-style or membership-driven setups, because it ensures that access rules remain consistent across environments.
After importing settings, validation is mandatory. At minimum, you should run a single AI generation, test a chatbot response, and check Plugin Status. Usage Logs and Execution Logs should show clean entries. Any blocked execution usually indicates missing API keys or environment-specific restrictions that need adjustment.
Once validated, the helper plugin can be safely deactivated or removed on production. It is not required for normal Aimogen operation and should not remain active unnecessarily on live sites.
A common mistake is attempting to migrate Aimogen by copying the database or using a full-site migration tool. This often brings logs, test data, scheduled artifacts, and stale execution state along for the ride. Configuration export avoids this entirely and keeps environments clean.
Another mistake is exporting settings from a newer Aimogen version and importing into an older one. Versions should match closely to avoid subtle differences in feature availability or defaults.
Best practice is to treat Aimogen configuration as portable infrastructure. Export it when behavior changes, version the exports, import deliberately, and always re-enter environment-specific credentials manually. This keeps AI behavior consistent, auditable, and safe across development, staging, and production.
In short, importing and exporting settings with the CodeRevolution helper plugin is the correct way to migrate Aimogen setups. It moves intelligence without dragging history, preserves control over API keys, and keeps AI automation stable across environments.
