Note, from the title, NOT moving to another PC but a second "instance" of BOINC running in the -same- PC. I have two Linux BOINC's (7.14.2) running, clients and managers, with their own choice of projects. (The motive, from long ago, was to facilitate resource management and to allow the CPU-only projects, for example, to run only at night when temperatures and PC usage are favorable while GPU projects run 24/7.)
One of the CPU projects, Asteroids@home, now has a GPU app and so I now want to move that project into the BOINC instance with all the other GPU apps.
I will run out the caches in both BOINCs and wait for all work reported, then shut off both BOINCs. So let's assume that as the starting point.
My first thought (based on the Remove then Attach thread) is to do the "Remove" action on the A@H project in its BOINC instance, then switch to the other BOINC and do an "Attach Project" (carefully selecting -returning user-).
But, the second thought, can I salvage anything from the BOINC project directory to either expedite the new "Attach" process or to bypass it altogether? It would be easy enough to copy the contents of the /project/asteroids... directory to its new BOINC home. And maybe tempting to copy all the project-specific .xml files (master_, account_, sched_request_, sched_reply_, job_log_, statistics_, etc.) from the source BOINC to the target BOINC directories. Is this just asking for (big!) trouble? Just trying to imagine that BOINC restarting, with all those files and directories present, might be happy to pick up where it had left off. I DO worry about the side effects regarding the client_state.xml file. Maybe that file is regenerated in the restart process - or, maybe not!
Thoughts or advice, anyone? Thanks...

I've not heard of anybody doing exactly that - they usually have too much of a struggle simply to set up two independent BOINC instances - but in principle it should work.

I wouldn't attempt to migrate any actual 'work in progress' (running tasks) - that would involve moving a slot directory as well, and you'd probably have to renumber it. Don't even go there.

So, suspend any tasks you have cached for the project you're moving. Let any running tasks complete, upload, and then report the results.

Stop both BOINC instances, move the project folder, move all the named files.

AND THERE'S MORE.

Carefully open the file 'client_state.xml' in a text editor - in the root of the BOINC instance you are removing the project from - and find this entire section:

<project>
    <master_url>http://asteroidsathome.net/boinc/</master_url>
    <project_name>Asteroids@home</project_name>
    ...
</project>
<app>
    ...
</app>
<file>
    ...
</file>
<app_version>
    ...
</app_version>
<workunit>
    ...
</workunit>
<result>
    ...
</result>
<project_files>
    ...
</project_files>

Not every section need be there, but keep reading until you reach the next

<project>

Leave that one alone. Now, CUT the whole section out of this version, and PASTE the whole thing into the other client_state.xml file - conventionally, they go in alphabetical order of project name.

It would be easier to describe if it had been written in conventional XML, with everything related to a project within the <project>...</project> tags, but it's too late for that. But I hope you can see the general 'shape' of the contiguous block you need to move. Ask again if not.

Yes, you can pre-move the Asteroids directory from the first BOINC instance to the other instance. But you are still going to have to add the project to the new instance to get the client_state updated with the new project.

I wouldn't move the project BOINC directory files and just let the new join process create new ones.

Project sucessfully moved. I'll outline the process here, for the benefit of future message searches.
@RH - pretty much followed your recipe, but included the "client_state_prev.xml" file as well as the "client_state.xml" file when moving the <project> block of statements.
@KM - I was brave enough to try RH's strategy. My thinking was similar to COVID vaccine trial volunteers, i.e. even if the outcome is bad it gives useful data to others coming down the same trail.
So here's the script, in which asteroidsathome (A@H) is moved from instance BOINC2 to instance BOINC1.

invoke NNT on ALL projects and allow caches to completely drain;
exit both instances of boinc client and boinc manager;
make backup copies of both BOINC1 and BOINC2 directories;
move /BOINC2/projects/A@H to /BOINC1/projects/A@H;
N.B.:  "move" means copy to destination AND delete from source;
move the following 6 project-specific xml files from /BOINC2/ to /BOINC1/;
  account_asteroidsathome.net_boinc.xml
  job_log_asteroidsathome.net_boinc.xml
  master_asteroidsathome.net_boinc.xml
  sched_reply_asteroidsathome.net_boinc.xml
  sched_request_asteroidsathome.net_boinc.xml
  statistics_asteroidsathome.net_boinc.xml
locate the block of xml statements starting with the <project> header relating to the asteroids@home project
  and ending at the line before the *next* occurance of <project>;
move that block from the /BOINC2/client_state.xml to the /BOINC1/client_state.xml;
  take care to insert the block at a place comparable to where it was removed;
repeat these two steps for /BOINC2/client_state_prev.xml to /BOINC1/client_state_prev.xml;

Resumed the BOINC2 client and manager. Event log showed no error messages. Remaining project started normally and, when removing the NNT restriction, downloaded new work.
Resumed the BOINC1 client and manager. Event log showed no error messages. All projects are shown, including the A@H project that was moved here. Removed NNT on projects one by one and each downloaded new work. asteroids@home now operational in the new BOINC instance.
Some chores remain, i.e. adjust resource shares and concurrent task limits, but nothing apparent at this time that is badly configured.
Thank you Richard and Keith for your interest. And I hope this may be helpful to future readers.
5/4/20 May the 4th be with you!

When setting up a new machine or clean install I normally just dump the account file in the BOINC data directory and when it starts it will auto-attach to the projects.

So in your case you’d finish off/report any work and shut down both instances. Copy the account file across and start that instance. It should attach automatically. The other instance you’d start up and then carry on. The same process should also work across machines.

---

MarkJ