Migration and reconciliation

The Integration screen provides one ordered Migration Center for every registered provider: compatibility scan, destination creation/mapping, authority strategy, safe preview, execution, reconciliation, and run history. Discovery and the compatibility report remain readable while execution is locked, so a site owner can see exactly what is supported before purchasing or renewing Pro.

Provider compatibility counts are cached for five minutes so opening the migration workspace does not repeatedly rescan provider tables. Use Refresh scan on a provider card whenever you need an immediate, nonce-protected rescan. Synchronization and reconciliation workers still read current provider records when they run.

Structured history filters such as content type and activity kind are preserved consistently by both ledger and member-view REST routes. Personalized responses remain private and bypass shared browser and page caches.

Available Pro strategies are:

• Move once to Cointacted — import available history or explicit opening

totals and then stop.

• Keep provider active; Cointacted on top — the provider remains

authoritative and Cointacted imports new movements or exact balance deltas.

• Compare only — report matches and conflicts without mutating either

system.

• Cointacted controls after cutover — Cointacted remains authoritative and

later provider changes are audited as conflicts.

One mapped reward domain always has one writer. Uncontrolled bidirectional mirroring is not enabled.

Every run also has an explicit data scope. For myCred and GamiPress, an administrator may select Points and balances, Achievements (myCred badges), Ranks, any combination, or all supported families. A rank-only run does not query point logs or achievement tables; an achievement-only run does not process ranks or point history. The same selection controls preview, execution, resume, and scheduled synchronization, and participates in the configuration fingerprint so a paused run with another scope cannot be reused. At least one family is required. Provider automation conversion remains a separate review-first workflow because it creates disabled definitions rather than importing member data.

The compatibility table lists supported and unsupported provider object families instead of hiding conversion gaps. Point types can be mapped with dropdowns or created from provider-recommended names, slugs, precision, and negative-balance policy without typing identifiers. Runs are processed in bounded batches. Each run stores authority, direction, initiator, adapter version, starting/final checkpoints, safe configuration, and counters. Each source record stores its mapping, normalized hash, outcome, and immutable retry/error attempts. Raw payloads are not retained.

Each point-type mapping also stores a versioned balance conversion policy. Administrators can preserve the source amount, import a percentage of it, or apply a positive decimal multiplier. Destination precision and one explicit rounding rule—nearest half-up, toward zero, down, or up—determine the final ledger amount. Calculations reject floats and use exact decimal strings for positive awards and negative deductions. The policy fingerprint is part of the source hash, and source amount, converted amount, and policy remain auditable.

Balance comparisons isolate the selected provider and provider point type's ledger contribution from the member's total Cointacted balance. Multiple native point types, native Automations, and another provider can therefore use the same destination without creating false drift. An opening-balance action posts only the transformed residual between the current provider total and that provider projection; it never blindly adds the full balance over already imported history. Submitting the same opening-balance approval again matches the original source snapshot and returns its existing immutable transaction; a changed provider projection cannot turn that retry into a false source-change conflict.

When Points and balances is selected, every completed myCred or GamiPress history pass continues into a bounded current-balance sweep. The worker walks member IDs and mapped provider point types in durable pages, compares each transformed provider total with that provider's Cointacted projection, and posts only a non-zero residual as an immutable reconciliation transaction. Matching members create no synchronization or ledger rows. Interrupted pages are replay-safe, ongoing profiles repeat the sweep only after completing the previous cycle, and no frontend request enumerates members. Preview runs show prospective residuals without mutation; report-only and Cointacted-authority runs create conflicts instead of correcting balances. During a one-time import, the worker also compares the provider's current total with the signed original amounts represented by imported history: it automatically corrects accumulated conversion/rounding drift only when that history is complete. A genuine history gap remains an explicit conflict/opening-balance decision. Ongoing provider-authoritative synchronization may apply a current-balance residual because that mode deliberately treats the provider as the continuing source of truth.

Preview runs write synchronization history and an isolated run-scoped pagination checkpoint, but no provider mappings, production resume checkpoint, or ledger movements. This allows a large dry run to traverse every source page without advancing a later real import. Interrupted live runs pause and can continue from their saved production checkpoint. Repeating an import is safe because external mappings, checkpoints, and ledger idempotency prevent duplicate movements. If a checkpoint is deliberately reset, matching rows are recognized without a second posting. A row whose provider fields changed after import is quarantined as a source_changed conflict; its original mapping and immutable transaction are not rewritten. Missing type mappings stop before the affected row advances the checkpoint, so the mapping can be supplied and the same run resumed. Reconciliation creates explicit conflicts; operator decisions are recorded as acknowledge, keep Cointacted, retry, or require an opening balance. Corrections use reversals or an explicitly approved opening entry.

Full-state removal checks are separate, explicit capabilities rather than a side effect of incremental synchronization. When a provider advertises earned- achievement full-state support, the Migration Center shows an off-by-default checkbox. A preview is non-mutating. Execution can revoke a disappeared grant only under provider authority; Compare-only and Cointacted-authoritative runs create reviewable conflicts. Durable absence evidence is stored separately from the original grant mapping, repeated scans are idempotent, and reappearing provider records are quarantined instead of silently undoing a reviewed revocation.

Current provider coverage

myCred and GamiPress point types, point movements, current-balance reconciliation, opening entries, resumable imports, and provider-to-Cointacted ongoing synchronization are supported. GamiPress achievement types, definitions, and earned occurrences are also supported: definitions are namespaced and versioned, source steps remain inspectable but inactive, earned timestamps and external IDs are preserved, and imported definitions award zero duplicate points because their provider reward is already present in the point log. Because deleted GamiPress achievement earnings expose no tombstone, ordinary imports retain their grants. An optional full-state scan can now detect the absence, preview its exact effect, and apply a reviewed provider-authoritative revocation. myCred badge levels and current earned state are also supported: each level is a separate non-repeatable achievement, exact issue times are preserved, and native requirements/rewards remain inspectable but inactive. myCred exposes current level state rather than a complete historical timeline, so missing issue times become conflicts and ordinary imports do not interpret a missing/divested row as permission to revoke. myCred rank conversion is now supported separately: point-type-specific definitions preserve thresholds, order, images, status, and manual/current/total behavior; stored member pointers become explicitly labelled opening observations because myCred has no rank assignment timestamp or immutable transition ledger. Later observed rank changes become versioned Cointacted history without mutating myCred. GamiPress rank conversion is also supported: native rank types become independent namespaced ladders, definitions retain exact ordering and inactive requirement semantics, and immutable User Earnings rows retain their stable IDs and original timestamps. A separate final state pass reconciles explicit current pointers and GamiPress's implicit lowest-rank default without inventing missing earning history.

GamiPress automatic awards and requirements now use a separate review-first conversion workflow. A scan stores provider-neutral proposals without enabling rules. Exact registration and approved-comment point awards/deductions can create disabled Cointacted Automation drafts after the administrator selects a mapped destination. Native count windows, interval limits, publishing/deletion lifecycle differences, achievement steps, rank requirements, and add-on triggers remain blocked with a concrete explanation. Publishing is never part of conversion. Source changes force a fresh review, and a change after conversion becomes a conflict instead of rewriting the existing draft. The conflict links to the draft and requires an explicit Keep reviewed draft decision after comparison.

myCred active hooks use the same review-first proposal repository. The adapter expands every point type, publishing post type, and comment recipient/state into an independent source head. Exact registration and simple approved-comment amounts can create disabled drafts. Native audience exclusions, activity counters, self-reply rules, private-publication behavior, publishing time limits, comment reversal/restoration behavior, and unknown add-on hooks remain blocked with their original sanitized settings attached for review. A changed source is revalidated and quarantined exactly like a changed GamiPress source.

The official Cointacted FluentCommunity addon contributes its own provider adapter. It can import native member engagement totals as explicit opening transactions and poll later totals as exact immutable deltas while FluentCommunity remains authoritative. FluentCommunity does not expose those current totals as a complete immutable reward log, so Cointacted labels this as snapshot migration and never invents historical transactions. Native level definitions become a dedicated Cointacted Community levels rank ladder, and current member promotions or demotions become versioned, replay-safe rank history. Preview does not create definitions or assignments. Provider, Cointacted, and report-only authority choices apply to both point totals and level state. Native seven-day, thirty-day, and all-time leaderboards can remain active while Cointacted boards appear beside them.

The semantic rank converter is part of Gamification's provider-neutral adapter contract rather than provider-specific core code. FluentCommunity, myCred, and GamiPress supply normalized ladder definitions and member state while reusing the same source hashes, immutable revisions, mappings, authority rules, conflicts, and assignment history. GamiPress additionally supplies immutable earning occurrences through the provider-neutral timed-transition contract. Automation proposals follow the same boundary: the shared proposal repository owns review state, hashes, decisions, and target links, while each provider adapter alone reads and translates its native requirement or hook schema.

Provider adapters and synchronization control classes are loaded on demand. An ordinary frontend, REST, or unrelated administration request does not load myCred or GamiPress implementation code. A synchronization cron is scheduled only while at least one enabled ongoing profile exists and is removed when the last such profile is disabled.

FluentCommunity runs independently select Engagement balances and Community levels. Choosing levels only avoids ledger balance writes; choosing balances only avoids rank-definition and assignment work.