Move a Local MCP Environment to Another Computer

Move a Local MCP Environment to Another Computer

Moving a local MCP environment means more than installing Feluda on a new computer.

The environment may include:

• Feluda user data;
• Studio workflows;
• Journal entries;
• local AI providers;
• downloaded models;
• a local MCP server;
• source files;
• local databases;
• output folders;
• protected credentials;
• permissions;
• RunFlows history; and
• scheduled workflows.

Move each part in a controlled order.

Keep the old computer available until the new environment has passed all required tests.

When a move may be needed

You may move the environment because:

• the old computer is being replaced;
• the old device is unreliable;
• more powerful hardware is needed;
• a team is standardising devices;
• the operating system is changing;
• the environment is moving to an approved workstation;
• local storage is being reorganised; or
• the workflow owner is changing.

The reason for the move affects the preparation and final cleanup.

Define the target environment

Before copying anything, record:

• target computer;
• target operating system;
• available memory;
• available storage;
• graphics capability;
• required ports;
• user account;
• expected local paths;
• local-network access;
• backup location; and
• migration owner.

Confirm that the new computer can run the selected local model and MCP tools.

Map the complete environment

Create an inventory of:

• Feluda version;
• Feluda user-data location;
• model runner;
• installed models;
• model endpoint;
• MCP server;
• MCP endpoint;
• required local services;
• source folders;
• output folders;
• local databases;
• credentials;
• permission rules;
• workflows;
• Genes;
• schedules;
• known-good tests; and
• external destinations.

Do not record raw secrets.

Keep the old computer unchanged at first

Do not uninstall Feluda or delete source data from the old device before the new environment works.

The old computer is your safest reference for:

• workflow settings;
• model names;
• local paths;
• MCP tools;
• permissions;
• expected results;
• schedule settings;
• write destinations; and
• normal runtime.

Treat it as the rollback environment during migration.

Pause risky automation

Before copying data:

• pause scheduled write workflows;
• stop active RunFlows executions;
• confirm no write tool is still running;
• confirm local files are not being changed;
• confirm local databases are ready for backup; and
• check external destinations for pending actions.

Read-only workflows may also need to be paused when consistency matters.

Create a current backup

Back up:

• Feluda user data;
• Studio workflows;
• Journal entries;
• important local sources;
• required output;
• local databases;
• model and runner records;
• MCP server records;
• permission records;
• schedule records; and
• recovery notes.

Use an approved encrypted destination when the backup contains sensitive information.

Confirm Feluda user-data locations

On Windows, Feluda user data is stored under:

%APPDATA%\Feluda\

This can include flows, journals, Genes, settings, and related user content.

On Linux, the user-data location is typically:

~/.config/Feluda/

Or:

$XDG_CONFIG_HOME/Feluda/

On macOS, confirm the active application-data location using the current Feluda installation guidance and the operating system's application-data tools.

Verify the backup before moving

Confirm that:

• the backup exists;
• expected folders are present;
• expected files are present;
• database exports completed;
• the backup date is correct;
• encryption works;
• the backup can be opened by an authorised user; and
• the original environment remains unchanged.

Do not begin the move with an unverified backup.

Record the local model setup

Record:

• model runner;
• runner version;
• model name;
• model version;
• model size;
• quantisation when relevant;
• context settings;
• local endpoint;
• startup behaviour; and
• normal hardware use.

Common endpoints include:

• Ollama: http://localhost:11434
• LM Studio: http://localhost:1234

Use the endpoint shown by the actual local runner.

Decide whether to copy model files

Copy model files when:

• exact reproducibility matters;
• the model may no longer be available;
• internet access is limited;
• the download is large;
• offline recovery is required; or
• the move must be completed quickly.

Otherwise, record the exact model and download it again through the approved runner.

Record the MCP server setup

Record:

• server name;
• server version;
• installer or package source;
• endpoint;
• port;
• startup method;
• tool list;
• source paths;
• destination paths;
• local services;
• authentication method;
• permissions; and
• known-good tests.

A local MCP server may depend on more than one local application.

Record protected credentials separately

Do not include raw:

• passwords;
• API keys;
• access tokens;
• database credentials;
• private headers; or
• client secrets

in ordinary migration files.

Record only:

• service;
• account owner;
• purpose;
• scope;
• expiry process;
• recovery method; and
• rotation owner.

Prepare the new computer

Before restoring data:

• install operating-system updates;
• create the intended user account;
• confirm storage;
• confirm memory;
• confirm graphics support;
• confirm firewall settings;
• confirm required network access;
• confirm backup access; and
• confirm the device meets organisational requirements.

Keep the device separate from production writes during initial setup.

Install Feluda

Install the current approved Feluda desktop application.

Open it once and confirm that:

• the Dashboard loads;
• AI Providers opens;
• MCP Servers opens;
• Workbench opens;
• Studio opens;
• RunFlows opens;
• Journal opens; and
• Schedule Manager opens.

Close Feluda before replacing user-data files when required.

Restore Feluda user data

Restore the backed-up user-data folder to the correct location for the new operating-system user.

Preserve:

• folder structure;
• filenames;
• file ownership;
• file permissions; and
• the selected backup version.

Reopen Feluda after restoration.

Verify restored Feluda content

Confirm that:

• Studio workflows appear;
• Journal entries appear;
• Genes appear when expected;
• settings are present;
• provider records appear;
• MCP connection records appear;
• RunFlows items appear; and
• schedules appear but remain paused.

Do not run write workflows yet.

Install the local model runner

Install the same approved runner or an approved replacement.

Common choices include:

• Ollama;
• LM Studio; or
• another compatible local endpoint.

Confirm that the runner starts normally.

Restore or download the model

Restore copied model files or download the recorded model again.

Confirm:

• exact model name;
• model version;
• model size;
• available storage;
• expected memory use; and
• expected startup time.

Test the model directly in the runner before connecting Feluda.

Reconnect the local provider

Open AI Providers.

Then:

1. select or add the local provider;
2. enter the correct base URL;
3. save the provider;
4. select Fetch Models;
5. confirm the required model appears; and
6. select it for testing.

A normal local provider does not require a cloud model key.

Test the model without tools

Open Workbench and select the local provider and model.

Send a simple message.

Confirm that:

• the intended model responds;
• no cloud provider is selected;
• response speed is acceptable;
• the runner remains stable; and
• the new hardware can handle the model.

Do not proceed to MCP testing until this succeeds.

Install the local MCP server

Install or restore the MCP server using the approved source.

Confirm:

• version;
• endpoint;
• port;
• startup method;
• local dependencies;
• source paths;
• destination paths; and
• expected tools.

A port used on the old computer may already be occupied on the new one.

Start the MCP server separately

Before connecting it to Feluda, confirm that:

• the process starts;
• the endpoint is reachable;
• the intended port is available;
• the firewall permits access;
• local dependencies are running;
• source folders exist; and
• output folders are writable.

Reconnect the MCP server in Feluda

Open MCP Servers.

Confirm or recreate:

• server name;
• endpoint;
• authentication method;
• account;
• connection state; and
• expected tools.

Use a clear temporary name such as:

Local Documents MCP — New Computer Test

Re-enter protected credentials

Re-enter secrets through Feluda's protected settings and the operating system's secure credential store.

Never paste them into:

• Workbench;
• Studio prompts;
• Journal entries;
• source files;
• screenshots;
• migration notes; or
• unencrypted archives.

Revalidate account scope

Confirm that the restored account has only the required:

• read access;
• write access;
• project access;
• workspace access;
• file access;
• database access; and
• destination access.

Do not recreate unnecessary old permissions.

Restore local source files

Copy approved source data to stable paths.

Confirm:

• complete files;
• correct versions;
• folder structure;
• file ownership;
• read access;
• duplicate filenames;
• local availability; and
• modification dates.

Cloud placeholders are not complete offline copies.

Restore output folders

Recreate or restore approved destinations.

Confirm:

• exact path;
• write access;
• available storage;
• file naming;
• overwrite behaviour;
• duplicate handling; and
• backup coverage.

Keep input and output folders separate when possible.

Restore local databases

Use the database's approved restore method.

Confirm:

• software version;
• database name;
• host;
• port;
• account;
• schema;
• record count;
• indexes;
• sample records; and
• backup date.

Begin with a read-only query.

Update paths for the new computer

Paths may change because of:

• different user name;
• different drive letter;
• different operating system;
• different home directory;
• different mounted volume;
• different project location; or
• different database location.

Update only confirmed source and destination paths.

Review cross-platform path changes

Windows paths may look like:

C:\Users\Name\Documents\Feluda\Source

Linux or macOS paths may look like:

/home/name/Documents/Feluda/Source

Review every workflow and permission rule that uses an exact path.

Restore narrow permissions

Open affected workflows in Studio.

Review:

• URL rules;
• IP rules;
• path rules;
• port rules;
• source scope;
• destination scope;
• read access; and
• write access.

Avoid copying broad old permissions without review.

Review local firewall rules

Confirm:

• model-runner port;
• MCP server port;
• database port;
• local-network access;
• blocked destinations; and
• whether the rule applies only to the intended application.

Do not open broad port ranges.

Compare the discovered tool list

Compare tools on the new computer with the old environment.

Look for:

• missing tools;
• renamed tools;
• new tools;
• duplicate tools;
• changed descriptions;
• changed input;
• changed output; and
• changed read or write behaviour.

Investigate every unexpected difference.

Run a known-good read test

Use the same non-sensitive test from the old computer.

For example:

Use only the enabled Local Documents Search tool.

Search for "local MCP migration test".

Return:
1. document title;
2. local source path;
3. returned summary;
4. last updated date; and
5. any warning.

Do not create or change anything.

Start a new Workbench conversation.

Review Workbench Activity

Confirm:

• the intended tool was called;
• the new local server provided it;
• input was correct;
• the correct source path was used;
• raw output was complete;
• warnings were understood;
• errors were absent or resolved;
• no repeated call occurred; and
• the final answer matched the result.

Compare old and new results

Use the same input on both computers.

Compare:

Check	Old computer	New computer
Tool
Source path
Record or file
Required fields
Warning
Runtime
Final answer

Investigate meaningful differences.

Test no-result and error cases

Test:

• no matching result;
• invalid input;
• blocked path;
• unavailable local service;
• unavailable source;
• timeout; and
• permission denial.

Confirm that the workflow stops safely and does not invent data.

Review Studio workflows

Open each important flow.

Confirm:

• provider;
• model;
• selected MCP tool;
• prompts;
• input mappings;
• output mappings;
• path references;
• permission rules;
• no-result paths;
• error paths;
• Emit blocks;
• write approval; and
• destination.

Update one workflow at a time.

Test in Studio

Use non-sensitive sample data.

Test normal, empty, invalid, and error paths.

Add Emit blocks when you need to inspect raw tool output or intermediate values.

Do not start with production writes.

Test in RunFlows

After saving a flow:

1. open RunFlows;
2. select the migrated flow;
3. provide known-good input;
4. review the tool call;
5. inspect raw output;
6. inspect intermediate values;
7. confirm the correct branch;
8. review warnings and errors; and
9. compare final output with the old computer.

Test write tools separately

Use a safe test destination.

Start with a draft-first instruction.

Confirm:

• tool;
• account;
• environment;
• record or file;
• current values;
• proposed values;
• destination; and
• reversibility.

Approve one exact action.

Verify write destinations

Inspect the real destination.

Confirm that:

• the intended item changed;
• only approved fields changed;
• the new computer used the correct path or account;
• the timestamp is correct;
• no duplicate appeared; and
• the action can be reversed.

Test offline operation

When the environment should work offline:

1. complete connected tests;
2. disconnect the new computer from the internet;
3. keep Feluda open;
4. keep the model runner active;
5. keep the MCP server active;
6. repeat the Workbench test;
7. repeat the RunFlows test; and
8. inspect the local destination.

Confirm that no hidden remote dependency appears.

Test after restart

Restart the new computer.

Confirm that:

• Feluda opens;
• the model runner starts;
• the model remains installed;
• the MCP server starts;
• endpoints remain correct;
• files remain mounted;
• databases start;
• credentials remain available;
• Workbench can use the tool; and
• RunFlows completes the known-good test.

Review power and sleep settings

For scheduled local workflows, confirm:

• sleep settings;
• laptop lid behaviour;
• battery-saving mode;
• automatic restart;
• login requirements;
• service startup; and
• power availability.

A sleeping computer may miss a run.

Review restored schedules

Keep schedules paused during migration.

For each one, confirm:

• flow;
• frequency;
• time;
• timezone;
• provider;
• model;
• MCP server;
• source;
• destination;
• write action;
• normal runtime;
• conflict warnings; and
• reviewer.

Timezone and local time may differ on the new computer.

Use a one-time schedule test

Before resuming recurrence:

• choose a safe flow;
• create a one-time run;
• confirm the computer is awake;
• confirm local services are running;
• review Schedule Manager;
• review RunFlows;
• inspect output;
• verify the destination; and
• check for duplicates.

Resume schedules gradually

A useful order is:

1. low-risk read-only flows;
2. important read-only flows;
3. low-risk local writes;
4. approved production writes; and
5. high-volume or overlapping schedules.

Monitor the first runs.

Keep the old computer as rollback

Keep the old environment available until:

• all important read tests pass;
• all required write tests pass;
• Studio workflows pass;
• RunFlows tests pass;
• offline tests pass when required;
• restart tests pass;
• one-time schedule tests pass;
• recurring runs are stable; and
• users can work from the new computer.

Do not run both production write environments at the same time unless the process is designed for it.

Prevent duplicate production activity

During the migration period:

• keep old write schedules paused;
• keep new write schedules paused until approved;
• use clear computer and connection names;
• use test destinations;
• check external records before retrying; and
• avoid simultaneous production writes.

Define the cutover point

The cutover is the moment the new computer becomes the active environment.

Before cutover, confirm:

• backup is current;
• new environment is tested;
• old schedules are paused;
• new schedules are ready;
• write destinations are verified;
• users are informed;
• rollback steps are known; and
• an owner approves the change.

Monitor after cutover

Review:

• model availability;
• MCP connection health;
• tool calls;
• runtime;
• warnings;
• errors;
• external destinations;
• duplicate actions;
• schedule history; and
• user reports.

Keep the old computer unchanged during the agreed rollback period.

Revoke old-device access

After the new environment is stable, decide whether the old device should retain access.

Revoke or remove:

• old credentials;
• MCP accounts;
• database accounts;
• network access;
• VPN access;
• local service startup;
• write permissions; and
• scheduled workflows

when they are no longer needed.

Remove old schedules

Confirm that no schedule remains active on the old computer.

Check:

• Schedule Manager;
• local operating-system tasks;
• MCP server startup tasks;
• model-runner startup;
• database jobs; and
• related external automation.

Clean up the old computer

Only after final approval:

• export any remaining required data;
• confirm the latest backup;
• revoke credentials;
• remove MCP connections;
• remove sensitive local files;
• remove local database copies;
• remove model files when required;
• uninstall Feluda when appropriate;
• remove local server software; and
• follow the approved device-cleanup process.

Do not delete shared or legally required records.

Verify cleanup

Confirm that:

• old tools no longer run;
• old schedules no longer run;
• old accounts cannot authenticate;
• old local services are stopped;
• old files are removed or archived correctly;
• external destinations receive no new activity; and
• the device no longer contains unnecessary protected data.

Update the environment record

Record:

• migration date;
• old computer;
• new computer;
• operating systems;
• Feluda version;
• model runner;
• model;
• MCP server;
• endpoints;
• source paths;
• destination paths;
• credentials reissued or revoked;
• permissions;
• schedules moved;
• tests completed;
• cutover approval; and
• cleanup status.

Do not include raw secrets.

Final migration checklist

Before closing the migration, confirm that:

• the old environment is backed up;
• the new computer meets hardware needs;
• Feluda is installed;
• user data is restored;
• workflows and Journal entries appear;
• the local model runner works;
• the model is installed;
• AI Providers finds the model;
• the MCP server runs;
• expected tools appear;
• credentials are re-entered securely;
• source and output paths are correct;
• databases are restored;
• permissions are narrow;
• a known-good Workbench test passes;
• Activity shows the intended tool call;
• no-result and error tests pass;
• Studio tests pass;
• RunFlows tests pass;
• write destinations are verified;
• offline tests pass when required;
• restart tests pass;
• one-time schedules pass;
• recurring schedules are resumed gradually;
• old-device access is revoked; and
• final cleanup is verified.

A local MCP environment has moved successfully only when the complete task works on the new computer and the old computer can no longer create unintended activity.