How to Migrate Client Projects Without Losing Context

List every active project, its owner, and the data that matters for continuing work. Include tasks, subtasks, statuses, dependencies, due dates, notes, files, client contacts, approval decisions, and unresolved follow-ups. Decide which historical material must remain searchable and which can stay in an archive.

Not every tool supports every field. When there is no direct mapping, document the workaround rather than silently dropping data.

A realistic project exposes problems that a clean to-do list misses. Choose one with subtasks, dates, a blocked item, an approval pending, and at least one shared file. Import it, inspect the result, and compare against the original before inviting collaborators or clients.

Check task counts and hierarchy, then inspect a sample of dates, notes, and files. Verify who can see and edit each project. Confirm that no client-facing link exposes private internal content. Recreate unsupported automations or reminders deliberately; do not assume they transfer.

Set a cutover date after the test passes. Tell collaborators which system is authoritative. Keep the old workspace read-only or available for reference during a defined transition period. Avoid updating two systems indefinitely, because they will eventually disagree.

Noddis's Import dialog supports CSV, Excel (.xlsx), and JSON, with source-specific mappings and a task preview before import. A supported Noddis JSON manifest can carry task hierarchy, due dates, status or completion, notes, weights, and duration estimates. The data available depends on the source file and its format; this is not a promise of a complete account-to-account migration.

Choose whether to create new projects or add tasks to an existing one, inspect the preview, and check the result with a small sample. Attachments, collaborator permissions, client portal links, approval history, and external automations need separate review. The workspace guide explains where imported work lives. If your existing tool is working well, a migration may not be worth the disruption.

Use inventory → map → test → verify → pilot → switch. Start with a representative active project, not your entire archive. Record what must survive: task titles, nesting, dates, status, notes, attachments, owners, approval history, and unresolved commitments. Decide which older records can remain archived in the previous system.

These are conceptual mappings, not a promise that every field imports automatically into Noddis. The Import preview shows the recognized tasks. Compare the saved hierarchy, dates, and notes with your source afterward, and recreate unsupported relationships or access settings deliberately.

Choose a project with a nested task, a future deadline, an overdue item, a file, and an unresolved client approval. After importing or recreating it, compare the source and destination side by side. Check counts and meanings, not only whether the import completed without errors.

1. Can you find the next action without reopening the old tool?
2. Are deadlines, statuses, and task hierarchy accurate?
3. Are file links accessible to the correct people?
4. Is the latest client decision preserved?
5. Are open follow-ups assigned and dated?
6. Have you checked what the client can see separately from the internal team?
7. Is there a rollback or read-only archive plan?

A short notice is enough: “We're updating our internal project workspace. Your deliverables and agreed deadlines are unchanged. If the way you access updates or files changes, we'll send you the new link and instructions before switching.” Do not promise zero disruption until you've tested permissions and links.

Switch after the pilot team can complete a normal week without relying on the old tool for active work. Keep the original records available until you have verified data and access. Avoid deleting the old workspace immediately after import. If Noddis is the destination, explore the live demo with sample work, then verify the import preview and saved records in your own workspace before moving the rest.