Migrate social schedulers without duplicate or lost posts

Answer first: migrate the operating system around the posts, not only the posts. Inventory ownership, access, future schedules, media, approvals, reports, automations, and provider IDs; pilot one low-risk account; then choose a cutover where only one scheduler can publish each item.

1. Define the acceptance contract

List required providers, account types, formats, time zones, approval roles, reports, exports, API/webhook consumers, retention needs, and offboarding controls. Mark each as pass, blocked, or not needed. Keep TikTok Direct Post, Snapchat access, guest approval, CSV import, bulk import, and historical analytics explicitly unverified unless the selected product documents and demonstrates them.

2. Build an ownership inventory

For every account record the business owner, provider administrator, current scheduler connection, token owner, recovery contact, and intended destination workspace. Remove passwords from the inventory. Verify that an employee, former agency, or personal developer account is not the only owner.

Migration inventory

Object	Minimum evidence	Cutover risk
ObjectConnected account	Minimum evidenceProvider identity, owner, role, access state	Cutover riskWrong identity or revoked grant
ObjectFuture schedule	Minimum evidenceTime, zone, format, campaign, current scheduler ID	Cutover riskDuplicate or missed publication
ObjectMedia	Minimum evidenceOriginal file, alt text, rights, required crop	Cutover riskBroken URL or unsupported codec
ObjectApproval	Minimum evidenceApproved version, decision owner, timestamp	Cutover riskRebuilding an unapproved draft
ObjectAnalytics	Minimum evidenceExport, metric definition, collection time	Cutover riskFalse continuity across definitions
ObjectAutomation	Minimum evidenceCaller, credential, scope, webhook destination	Cutover riskHidden writes after cutover

3. Export what actually exists

Use vendor exports where available and retain their schema notes. Export scheduled and draft content, media references, account mapping, team roles, approval records, and analytics separately. A CSV rarely contains media binaries, thread relationships, remote provider IDs, comments, or complete approval history. If an export is missing, label it missing; do not claim the new system imported it.

Create validation fixtures before loading customer rows: UTF-8 with and without BOM, multiline Arabic, commas and quotes, emoji, Arabic-Indic and Western digits, an invalid time zone, an expired media URL, a duplicate source ID, and an unsupported provider-only column. Record the expected decision and stable error code for each fixture. The bulk CSV guide defines a portable staging contract; it does not establish that Naasher has a general importer.

4. Pilot one representative workspace

Choose low-risk accounts that exercise the hard requirements: Arabic mixed-direction copy, image/video, a reply chain or carousel, approval, and one failure case. Connect through each provider's official authorization screen. Test revoke/reconnect and verify the visible remote result.

5. Create a no-duplicate cutover

Freeze edits for a named window. Assign every future item to exactly one scheduler. Cancel or archive the old copy only after the new copy is approved and identifiable. Keep an exception list for items that must remain native. During the cutover, monitor local job state, provider response, and remote visibility separately.

6. Preserve a rollback

Rollback means more than reconnecting the old tool. Define who decides, the deadline, which items move back, how duplicates are prevented, and which credentials remain valid. Test the rollback on the pilot before the main cutover. Do not delete the old workspace or exports until the retention owner approves.

Retain the export digest, batch ID, source-row-to-local-ID map, and every per-target remote identifier. Separate records that never entered a queue from jobs already accepted by a provider. A rollback may cancel the first group safely while the second requires remote reconciliation or authorized removal; deleting local rows is not a remote rollback.

Naasher as a migration target

Naasher can be one target for supported providers, Arabic/English composition, separate workspaces, approval activity, analytics, REST, webhooks, and MCP. It does not currently promise guest approval or a general CSV/import path. TikTok is an inbox-upload workflow rather than audited Direct Post, and Snapchat ordinary production publishing remains blocked pending provider approval. Plan manual rebuilding and native fallbacks for unsupported requirements.

7. Offboard and reconcile

After two stable cycles, revoke old scheduler grants, rotate keys and webhook secrets, remove former staff, and retain the approved export. Reconcile future schedules, provider identities, and remote posts one final time. Record known historical gaps instead of manufacturing continuity.

The migration is complete when access ownership, every future item, and every automation has one accountable home—not merely when a connection screen turns green.