Migrating to Siren

If you’re coming from another WordPress affiliate plugin, the core workflow will feel familiar. You have partners, they promote your products, and you pay them when sales happen. But Siren’s architecture differs from other tools in ways that matter, and understanding those differences before you start will make the transition smoother.

This page covers the structural differences that apply regardless of which plugin you’re migrating from. For field-by-field mapping tables and platform-specific details, see the individual guides:

Use Beacon for migration assistance

There isn’t an automated importer that moves your old plugin’s data into Siren today. Migration is a manual concept-mapping exercise, and the fastest way through it is to work with Beacon, Siren’s free AI assistant. Beacon knows Siren’s architecture inside and out, so you can describe your existing setup in plain English (current programs, commission rates, payout structures, integrations) and it’ll help you translate the pieces into a Siren recipe you can install. If you’re not sure whether a specific feature from your old plugin has an equivalent in Siren, ask Beacon before you start digging through the mapping tables below.

Start by describing your current program to Beacon and asking for a recipe that matches. Use the platform-specific guides below as a reference for the terminology and edge cases Beacon should know about.

How Siren thinks about incentive programs differently

The biggest difference between Siren and other affiliate plugins is where the rules live.

In most affiliate plugins, commission rates are attached to affiliates. You set a global rate (say, 20%), then override it per affiliate when someone negotiates a better deal. The affiliate is the center of the system, and the commission structure is a property of the affiliate.

Siren flips this. Commission rules live in programs, and collaborators are enrolled in those programs. A program defines what triggers a reward, how the reward is calculated, and who is eligible. If you want different rates for different situations, you create different programs instead of per-affiliate overrides.

This means you can run an affiliate program that pays 20% on sales alongside a content creator royalty program that pays 50% on courses, alongside a performance bonus program that distributes a pool of rewards monthly. Each program has its own rules. The same collaborator can be enrolled in all three and earn from each one independently.

In other plugins, achieving this kind of setup requires creative workarounds or isn’t possible at all. In Siren, it’s the default way the system works.

One sale, multiple payouts

In AffiliateWP, SliceWP, and most other plugins, a sale creates one referral (or commission) record. One sale, one payout, one affiliate gets credit.

Siren separates the “what happened” from the “what’s owed.” When a sale occurs, Siren creates a conversion, a record that says “this sale was attributed to this collaborator through this program.” The system then calculates what’s owed and creates an obligation, a record that says “you owe this collaborator this amount.”

Because conversions and obligations are separate, one sale can create multiple obligations. If a customer clicks an affiliate link from Steve and then buys a course created by Brad, Steve might earn a 25% affiliate commission and Brad might earn a 50% royalty. Two obligations from the same transaction. The programs don’t interfere with each other because they’re tracking different contributions.

If you only ever need one affiliate earning one commission per sale, this separation is invisible. It works the same way. But when your incentive structures grow beyond the basics, the separation is what makes it possible without workarounds.

This also means obligations can exist without conversions. If you need to pay a collaborator for something that didn’t come through the normal attribution pipeline, like a negotiated bonus or a manual adjustment, you can create an obligation directly.

Programs replace global settings and per-affiliate overrides

Most affiliate plugins have a settings page where you configure one global commission rate, then provide per-affiliate or per-product overrides when the global rate doesn’t fit. The more exceptions you add, the harder the configuration is to reason about.

Siren doesn’t have global commission settings. Instead, each program defines its own rates, triggers, and eligibility rules. If you need different rates for different situations, you create a program for each situation rather than layering overrides on top of a global default.

Program groups handle the case where multiple programs could apply to the same sale. A program group bundles related programs and ensures only one fires per conversion, using rules like “newest engagement wins” or “oldest engagement wins” to break ties.

Distributors handle bonuses and scheduled rewards

Programs pay out per transaction. When a sale happens, the program evaluates the conversion and creates an obligation. But some incentive structures don’t work that way. Performance bonuses, profit shares, and milestone rewards are based on what someone did over a period of time, not on a single sale.

That’s what distributors are for. A distributor tracks collaborator performance over a period (weekly, monthly, or yearly), accumulates metric scores based on tracked events, and then distributes rewards when the period ends. The reward can go to the top performer, be split proportionally by score, or be divided evenly among everyone who participated.

Most affiliate plugins don’t have anything like this. Some offer add-ons for performance bonuses or tiered rates, but those tend to be limited to a few fixed metrics and simple threshold logic. Siren’s distributors can track any combination of events (sales, course completions, blog visits, coupon uses, and more) and use configurable point values to weigh different contributions. The individual migration guides cover which competitor add-ons map to distributors and how.

If you’re coming from a plugin where you’ve been working around the lack of scheduled rewards, distributors are likely the feature that will change the most about how you think about your incentive programs.

Tracking is more granular

Other plugins track referral link clicks as “visits,” a single record that ties a click to an affiliate. Siren breaks this into two concepts.

An opportunity represents a trackable visitor. When someone clicks a referral link, Siren creates an opportunity that says “this person arrived through this referral mechanism.”

An engagement represents a credit claim against a specific program. One opportunity can create multiple engagements if the collaborator is enrolled in multiple programs. Each engagement tracks the collaborator’s claim separately, with its own score that program groups can use to determine which program wins.

For migration purposes, a “visit” from another plugin maps most closely to an opportunity. Engagements don’t have a direct equivalent in other systems because other systems don’t have multi-program attribution.

Commission calculations are modular

Most affiliate plugins make fixed decisions about how commissions are calculated. Discounts are always subtracted before the commission is computed. Shipping and tax might have a toggle to include or exclude them. Fees are silently included or ignored. You get a few checkboxes and the rest is hardcoded.

Siren uses a modular system called transaction compilers. Each component of a transaction (line items, discounts, fees, shipping, taxes) is an independent module that you enable or disable per program or per distributor. If you want commissions calculated on the pre-discount amount, don’t enable the discounts compiler. If you want subscription signup fees included in the calculation, enable the fees compiler. Each combination produces a different commission base, and you choose what makes sense for each program.

On top of that, the line items compiler has composable filters that narrow which products in a transaction are eligible. You can filter by product category, SKU, product type (products vs. subscriptions), or collaborator ownership. Multiple filters combine with AND logic, so a single transaction with five items might only pay commission on the two that pass all filters.

No competitor offers this level of modularity. The best any competitor does is two toggles (shipping and tax). None of them let you choose whether discounts are factored in, none have a fee toggle, and none offer SKU-based or product-type-based filtering.

Most affiliate plugins handle per-product and per-category commission rates by putting rate fields directly on product edit screens or in category settings. If Product A should pay 30% and Product B should pay 15%, you set those rates on each product. Siren doesn’t have per-product rate fields. Instead, you create a program with the rate you want and use line item filters to control which products it applies to. A 30% program filtered to Product A and a 15% program filtered to Product B achieves the same result.

This is a different workflow, and it requires more upfront setup when you have many distinct rates. The advantage is that all commission logic lives in named programs rather than being scattered across individual product settings. It also means filters compose with each other. A program that pays 25% only on subscription products in the “courses” category owned by the collaborator is a single program configuration. In other plugins, you cannot combine product-level rates with category rates with affiliate-specific rates in a single coherent rule.

The individual migration guides cover the specific per-product and per-category capabilities of each plugin and how to restructure them as Siren programs.

Collaborators are WordPress users

In Siren, every collaborator is a real WordPress user account. AffiliateWP does this too, but Siren leans into it more heavily. The collaborator portal, role-based permissions, and dashboard access all build on WordPress’s native user system.

The term “collaborator” instead of “affiliate” reflects a broader intent. An affiliate is someone who promotes products through referral links. A collaborator might do that, but they might also be a course creator earning royalties, a co-founder tracking profit shares, or a salesperson earning bonuses. The label is deliberately wider because Siren’s program system supports all of these roles.

What Siren doesn’t have (yet)

A few features common in other affiliate plugins aren’t in Siren today.

Most affiliate plugins include a dedicated section for managing creatives like banners, text links, and promotional materials. Siren doesn’t, because WordPress’s block editor makes it straightforward to create pages with promotional materials. If you need a structured creative library, a custom post type handles it. In practice, customers haven’t needed a built-in system for this.

Lifetime commissions, where a customer is permanently linked to an affiliate so the affiliate earns on all future purchases, are on the roadmap but not implemented yet.

Campaign tracking lets affiliates tag their referral links with a parameter like &campaign=email to see which channel drove traffic. This could be added if customers need it, but nobody has asked for it so far.

Some plugins support multi-level affiliate structures where an affiliate earns from their sub-affiliates’ sales. Siren doesn’t do this, and it’s not on the roadmap. Siren’s multi-program approach solves many of the same problems by rewarding different kinds of contributions independently, without the MLM structure.

What to expect during migration

The typical migration involves moving three things: affiliate accounts, historical commission data, and tracking codes.

Affiliate accounts map to collaborators. The user accounts themselves may already exist in WordPress. The migration creates collaborator records linked to those users, enrolls them in the appropriate programs, and assigns tracking aliases that match their existing referral codes so published links continue to work.

Historical commissions can be imported as completed conversions and fulfilled obligations. The data won’t participate in Siren’s attribution pipeline (it’s historical, not active), but it preserves the record so collaborators can see their earning history.

Tracking codes become aliases in Siren. If an affiliate’s referral link used ?ref=123 or ?ref=janedoe, that code is stored as an alias so the URL continues to resolve. Siren’s alias system preserves history, so even if the code is later changed, the old one keeps working.

Active browser cookies from the old plugin won’t transfer. If a customer clicked an affiliate link before the migration but hasn’t purchased yet, that attribution will be lost unless you handle it manually. This is a narrow window for most sites, but worth noting if you have long cookie durations.

See the platform-specific guides for detailed field mappings and step-by-step considerations.