Replace a Tool Without Losing Your Work | Heidelberg AI Curriculum
T16-L04
Choose & Evaluate AI Tools · Integrator
Replace a Tool Without Losing Your Work
Rehearse a real migration on copies, inspect portable and nonportable components, restore useful work in an alternative, and prepare a reversible cutover with explicit success criteria.
Your tool has become expensive, stopped fitting the job, or announced that a feature is going away. You find an Export button and download a ZIP file. Are you ready to leave?
Only if the work can continue elsewhere. An archive may preserve text while losing relationships, formulas, permissions, prompts, attachments, or the automation that made the text useful. A successful migration means that an intended user can complete the agreed job in the alternative, using restored information, with important losses explicitly resolved.
In this book, choose one real workflow and rehearse its migration on copies. Open an export, inspect it, restore useful work in a real alternative, and exercise a reversible switch. Keep the original authoritative while you learn. Your result is a demonstrated migration option, not merely a proposed exit strategy.
L4 is Integrator: company or lab systems and real data are in the loop. Your rehearsal uses public, synthetic, or explicitly approved copies, but it must account for the actual relationships a later authorized cutover would affect. A disconnected demonstration cannot establish that a shared operational workflow will survive replacement.
What you will be able to do
Inventory the content, behavior, access, and integrations that make a tool useful.
Distinguish portable files from components that require rebuilding or retirement.
Inspect exports and restore an agreed task in an alternative.
Reconcile edits made during a transition without losing or duplicating work.
Demonstrate rollback and define when a live cutover may proceed.
1. Structure: define the work that must survive
Begin with the reason to replace the tool. “The new one looks better” is not enough to guide difficult tradeoffs. Name the problem: a retirement deadline, unacceptable review effort, unavailable export capability, rising total cost, or a required feature the present route cannot provide.
Then identify one useful unit of work. For a writing assistant, this might be opening approved source notes, applying a saved instruction, producing a draft, and storing its accepted version. For an agent, it may be editing a project and running its existing check. For a knowledge workspace, it may be finding the current procedure and following its linked attachment.
Use this migration brief:
Current tool, account/workspace, and accountable owner:
Reason to consider replacement:
Workflow and users who depend on it:
Chosen alternative and why it is plausible:
Copied material allowed in the rehearsal:
Must-survive content and behavior:
Acceptable differences and explicitly unacceptable losses:
Dependencies and people affected:
Rehearsal boundary; live work remains authoritative at:
Success criteria; rollback trigger; decision date:
Keep the project yours. The optional worked route later uses Notion content restored into Obsidian for a small read-and-edit reference workflow. It does not require choosing either product. You can follow the same method with another pair whose official documentation supports the transfer you need.
The distinction from T16-L03 matters. L3 asks whether evidence supports relying on a tool for a defined workload. L4 asks whether your existing work can actually move into an acceptable alternative. A high evaluation score does not transfer files, repair links, or reconnect a scheduled job.
2. Understand: inventory what “my work” includes
Walk through one real work item and list every object it touches. Look beyond the visible document. An agent project may depend on repository instructions, skill files, model settings, credentials, an execution environment, and an external destination. A workspace may contain a database view that looks like a table but also filters, relates, and calculates records.
Make a compact inventory. Use portable, rebuild, archive-only, and unresolved as decisions rather than assuming everything will import:
Component
Current location
Target representation
Decision
How to verify
Accepted documents
Workspace pages
Markdown or native documents
Portable if inspected
Open and compare content
Attachments
Upload storage
Local or target-managed files
Portable if included
Open the files themselves
Relationships and IDs
Database properties
Target links or mapping table
Rebuild or unresolved
Follow both ends of a relationship
Formulas and views
Database configuration
Target formula or manual procedure
Rebuild
Recalculate a known example
Prompts and skills
Saved assistant settings
Reviewed text/configuration
Portable with adaptation
Run the intended task
History and comments
Product-specific state
Reference archive or target history
Often archive-only
Retrieve a required past decision
Access and integrations
Accounts, apps, schedules
Target-specific grants and routes
Rebuild
Check access and one end-to-end event
These are prompts for inspection, not claims that every product exports these objects. Record actual format support, plan restrictions, and omissions for the selected route. Include owners of shared objects; being able to view a page does not necessarily give you permission to export or redistribute it.
Portability has layers. Text may survive while formatting changes. Values may survive while formulas become static. Files may survive while URLs still point back to the old provider. A prompt can be copied while its model-specific settings and tool names become invalid. Write the required meaning and behavior, not only the desired filename extension.
Do not copy credentials into the migration pack. Record the credential's purpose, owner, storage location reference, and required target permission. Reauthorize through the destination's approved mechanism. Security design belongs with T12-L04; connector implementation belongs with T14-L04. This book follows those boundaries through the transfer.
Try the simplest route that preserves the required work: native export plus native import, or an official importer. Sometimes plain files and an existing editor are enough. Sometimes rebuilding one view is cheaper than trying to preserve a complex application in full.
Read both sides of the transfer. The exporter's claim that it produces Markdown does not establish what the destination accepts or reconstructs. A destination importer may prefer HTML because it includes information the source's Markdown export omits. The optional Notion-to-Obsidian route is a concrete example of this distinction.
If an LLM helps convert instructions or explain a schema, preserve the originals and inspect the conversion. Ask it to list uncertain mappings rather than invent equivalents. Use an agent only when actual file operations justify it, and confine it to the copied project. A skill can describe the target conventions; it cannot prove that the migration succeeded.
Treat the /tools catalogue as a place to find leads. The editorial snapshot available on 2026-09-09 records all 145 entries as unverified. Neither inclusion nor an open-source label establishes endorsement, portability, or compatibility. Check the chosen products' current official instructions and your own restored result.
A different interface is not necessarily an independent exit route. Two applications can rely on the same provider, account, or hosted storage. If leaving that dependency is the purpose, verify where the alternative stores information and performs model processing. Conversely, if only the interface is the problem, replacing it while retaining the provider may be entirely sufficient.
4. Build: create a representative rehearsal copy
Choose a small slice containing the features that matter. Include an ordinary item, a nested or linked item, an attachment, and any formula, history, or integration required by the workflow. A single clean note cannot stand in for a workspace that depends on relational data.
Copy the material into a clearly labelled rehearsal area using the source platform's supported controls. Confirm that copy operations did not retain live automations or shared write destinations. Disable those in the rehearsal. Use test destinations for events; do not send messages to real recipients just to see whether a connector works.
Before export, record counts by meaningful object type and a few stable identifiers. Open the source attachment and note its identity. For a tiny slice, inspect every object; for larger transfers, reconcile complete counts and identifiers, then inspect a justified sample of content and every critical behavior.
Save the export request date, completion date, source workspace, scope, format, and exclusions. Exports can be delayed or limited by access. A missing page may have been excluded by permissions rather than deleted by an importer. Diagnose the earliest point where it disappears.
Keep an untouched export and make a separate working copy for extraction or conversion. Use descriptive names such as source-export-YYYY-MM-DD and restore-rehearsal. If a checksum facility is already available, use it to identify the archive you inspected. A checksum establishes byte identity, not completeness or usability.
5. Open the export before importing it
Extract the working copy with your normal archive tool. Read its manifest or index if provided. Open actual documents and attachments, rather than relying on the ZIP filename or the successful download notification.
Check the following against your inventory:
Are all expected objects present, including nested content and files?
Do text encoding, dates, identifiers, and units retain their meaning?
Are links local, public, or dependent on the old account?
Are tables values only, or do their relationships and calculations survive?
Are comments, history, access rules, and instructions included or absent?
For CSV, use an import dialog that lets you inspect column types. Leading zeros, date interpretations, delimiters, and embedded line breaks can change meaning. A record ID such as 0042 is not necessarily the number forty-two. Compare it before and after import.
For an HTML archive, open a required page and follow its links. A browser showing a familiar page does not prove that attachments are inside the archive: the page may fetch them from the original service. Inspect link destinations and, where appropriate, open the copied archive without network access to check local completeness.
Chat history requires similar care. OpenAI's fetched ChatGPT documentation describes eligible account exports and tells users to inspect the downloaded ZIP. It does not establish that another assistant can restore conversations, tools, or memory from that archive. A readable history can be valuable as a reference without being executable state in a replacement product.
Write down omissions immediately. “Comments absent; the owner requires two decision comments; preserve them as approved reference notes” is actionable. “Export successful” hides the gap.
6. Restore into the alternative and resume work
Create an empty, clearly named destination for the rehearsal. Import using the destination's documented method and preserve any warnings. Avoid mixing an unproven import with an existing working collection; duplicate records and ambiguous identities make diagnosis harder.
Reconcile the destination with the source inventory. Match stable IDs where possible. Otherwise keep a simple source-to-target mapping for critical pages, records, and integrations. Check content as well as counts: ten imported pages can include one duplicate and omit one important original.
Then perform the real task. Find a required item through the normal interface, open its attachment, edit a copied field, save, close, reopen, and verify the change. If the workflow needs a calculation, change an input and check the recalculated result. If it uses an assistant, supply the restored source and adapted prompt and inspect the resulting artifact.
Use this receipt for each must-survive capability:
Capability:
Source object and target object:
Action performed in the alternative:
Expected result:
Observed result and evidence location:
Pass / repaired and rechecked / blocked / intentionally retired:
Loss or behavioral difference:
Owner accepting that difference:
An unresolved critical capability blocks the proposed replacement scope. You can narrow the migration to a separable workflow, choose another route, or retain the current tool while addressing the gap. Do not rename a failed migration as successful merely because some text is readable.
7. Optional worked route: a reference workspace into local Markdown
This is a source-backed procedure to attempt, not an observed migration. It is suitable only if your selected workload is reading and editing reference material without requiring Notion's collaborative database behavior.
In an authorized disposable Notion workspace, create or copy a small reference pack: a home page, two linked procedure pages, and an approved attachment. Add a tiny table if your real workflow needs one, and specify whether static values are enough. Preserve a named source identity for each item. Do not export a real shared workspace for this example without its owner's authorization.
The fetched official Obsidian instructions recommend HTML for their Notion ZIP importer, rather than Notion's Markdown export. For the disposable workspace, use Notion's workspace settings, choose Export all workspace content, select HTML, include everything, and enable folders for subpages. Confirm the actual options in your installed version and account.
Download the ZIP and keep the original. Extract a working copy, open the home page, follow the two procedure links, and open the attachment. Compare the small pack against your inventory. Notion documents that pages the exporting account cannot access may be omitted and that an exported workspace cannot simply be reuploaded to recreate it.
Create a new Obsidian vault for the rehearsal. Through Obsidian's supported plugin settings, install and enable the official Importer if permitted. Open Importer, choose Notion (.zip), select the original ZIP, and choose the destination folder. Enable the documented parent-page subfolder option if you want that organization. Review the template preview and then import.
The file-import route does not require a Notion API token or an internet connection for the import itself; obtaining the export and installing software may require connectivity. The fetched documentation explicitly says this route does not preserve databases. Do not infer that a visible folder of notes reproduces database formulas, views, or relationships.
In the imported vault, locate the home page, follow both internal links, open the attachment, and edit a procedure sentence. Close and reopen the vault. Open the resulting Markdown in an ordinary text editor as a separate readability check. If offline access is part of your requirement, repeat the reading task offline and confirm that required assets remain available.
Suppose, illustratively, that text and the attachment survive but a linked table becomes static records. If your workflow only needs reference values, the owner may accept that documented difference. If it depends on a formula recalculating due dates, this route has not met the requirement. Rebuild and check that function or choose another alternative before claiming success.
Obsidian's current documentation also describes a distinct API-import route with different capabilities and limitations. It is not silently substituted here: it requires an integration token and a separately authorized data path. A different route means a different rehearsal and evidence record.
8. Restore integrations without duplicating real actions
Return to the inventory and follow every incoming and outgoing dependency. Include scheduled jobs, watched folders, URLs in shared documents, webhooks, model endpoints, service accounts, and manual handoffs. Even a successful content migration can break because a colleague's bookmark still opens the abandoned copy.
For each dependency, record its owner, old target, proposed new target, access scope, trigger, and expected result. Recreate only the connection the task needs. Use separate test credentials and destinations where the platform supports them; never copy a production secret into a public mapping table.
Send one labelled synthetic item through the rehearsal path. Verify arrival at the intended destination, the required fields, and exactly one expected effect. Exercise a missing or invalid input and check that the workflow reports it rather than silently dropping work. Check ordinary user access, not only an administrator's view.
Keep only one live writer to a real destination during cutover. Running old and new automations together can send duplicate messages or overwrite records. Shadow comparison is useful when the new path has no external effects; otherwise use test destinations or a deliberately isolated batch.
Rebuilding a connector is T14-L04 work. Operational connector monitoring belongs with T14-L05. Your migration evidence must still show that the particular dependency worked after its target changed.
9. Plan a staged, reversible cutover
Define success before switching users. For example: every required object reconciles; all critical links and attachments open; the chosen task completes under ordinary permissions; the scheduled test arrives exactly once; and one designated user can resume work within the agreed time. Choose thresholds for your workload, not a generic availability target.
Use a short sequence:
Stage
Authority for new work
Evidence needed to advance
Rehearsal
Original system
Restored copied task and repaired gaps
Limited pilot
Explicitly assigned subset
Users complete work; changes accounted for
Cutover
New system after a stated cutoff
Final reconciliation and dependency checks
Observation
New system; old retained read-only
Normal work remains usable during agreed window
Retirement
New system
Retention, access removal, and continuity verified
Choose how to handle edits after the initial export. A short write freeze is often simplest for a small workflow. Announce its start, finish current work, export the final changes, reconcile, and then open the destination for writing. If a freeze is impossible, keep an explicit change log and reconcile every changed record before switching authority.
Do not promise automatic bidirectional synchronization unless it exists and has been checked. If a user edits both systems, record the conflict and ask the responsible owner which value is authoritative. Never silently choose the newer timestamp when it might represent an incomplete or unrelated edit.
Write the rollback steps in executable human terms: stop the new writer, preserve new work, identify changes since the cutoff, reconcile them back through the agreed route, restore the original entry point, and verify one useful task. Rollback is not simply turning the old service on if new records exist only in the replacement.
In the rehearsal, create one new target-only item, simulate the rollback decision, and return that item to the original rehearsal copy or agreed recovery store. Reopen it and repeat the task. Record duration and remaining limitations. This proves more than an untouched old account sitting beside the new one.
10. Hand over the migration option honestly
Give the owner this compact decision record:
Migration state: rehearsed / pilot / live cutover / blocked
Source and target identities; export date and cutoff:
Scope actually restored:
Must-survive checks and observed results:
Portable components; rebuilt components; accepted losses:
Unresolved gaps and their effect on the decision:
Integration owners and verified routes:
Authority for edits at each stage:
Rollback trigger, steps, owner, and rehearsal result:
Retention location, access, review date, and deletion authority:
Next authorized action:
Ask an intended user to complete the restored task without your oral directions. If they cannot find the right collection or need your old account to open an attachment, the handoff has found a real migration defect. Fix it or narrow the claim.
Do not delete the original during the rehearsal. For a later authorized retirement, retention and revocation are separate actions, handled in T16-L05. Communication and supporting users through changed habits belong with T13-L04; they complement, rather than replace, the restore evidence.
Your finished learning result is a usable alternative on copies, an inventory of what survived, and a demonstrated return path. If a critical capability remains blocked, report a partially restored option with that blocker. That is useful evidence for choosing the next route, but it is not migration success.
Sources and limitations
The following primary sources were fetched on 2026-09-09. This is their access date; it is not an inferred publication or update date.
OpenAI ChatGPT export help (opens in a new tab): export eligibility and inspecting downloaded contents. Eligibility varies by account and workspace; an available export is not a cross-product restore promise.
No product migration, account export, plugin installation, or classroom exercise was performed while authoring. Worked outcomes are explicitly illustrative. Interfaces and import capabilities change; use current official instructions and record what your own rehearsal actually restores.