In general, here's how I would do the migration to minimize the effect on existing users and allow you to have both the old and new schema active at the same time.

1. Stop dbremote from running on the consolidated and ensure that you are the only connected user to the consolidated database during steps 2-10. I'm not 100% sure it's necessary, but I'm very paranoid, and being the only connected user will definitely avoid possible concurrency issues while you change the schema of the consolidated.
2. For each table that includes a blob column, alter the publication such that the table definition includes all the columns of the table that you are replicating, not the entire table.
3. Create the new blob table in the consolidated database. Do NOT add it to any publication at this time.
4. For each table that includes a blob column, add a new column to the table that will eventually have a foreign key relationship to the new blob table. Because you've altered the table definition in the publication to a list of columns that does not include this new column in step 1, data in this new column will not be sent to existing remote database.
5. For each table that includes a blob column, populate the new blob table with the blobs that currently exist in the table, change the new column on the table to reference the primary key of new row you just inserted into the blob table, and then create a foreign key on the table to the new blob table when all the rows have been added.
6. For each table that includes a blob column, write triggers so that changes to the blob column in the table (insert, update + delete) are also reflected in the new blob table
7. Write triggers on the new blob table (insert, update + delete) so that changes to the new blob table are reflected back in the original table. Aside : I know what you're thinking. I've just doubles the size of my consolidated and created a whole pile of triggers to maintain. This is harder to maintain now than when we started this whole process. Patience, there will be short term pain for long term gain.
8. Create two new publications in the consolidated, one called mainPUB and one called blobPUB. These two publications will define the schema of the two databases for you new schema. Ensure that the mainPUB schema does NOT include the blob columns one the base tables, and blobPUB will likely just include the new blob table.
9. Create two remote users called mainUSER and blobUSER and subscribe them to the two new publications.
10. Extract remote database for these two new remote users. You now have two databases will your new schema and data, and only one copy of the blobs in these new database, in the new blob database. Changes made to the tables in these two new databases will be sent up the the original consolidated database, and changes made in the original consolidated (either directly or from all your remote users) will be sent to the new databases. These two new databases are now your NEW consolidated databases for your new schema. Create new remote users on these databases and extract new database for users as they migrate to the new schema. You now have both the old and new schema active at the same time.
11. Once all the old schema databases have been migrated to the new schema, you can dispose of the original consolidated database. Ensure that all the changes in the old consolidated have been sent to the new consolidated databases, and then take it offline (forever). Remove references to the consolidated users in the new consolidated databases that reference the old consolidated database.
12. Celebrate a successful migration with a beverage of your choosing.

Reg

PS: Sorry for the late reply. I'm only working part time remotely right now, and my hours vary greatly. Hopefully those interested are still following this thread.

While this forum has been rather quiet (and boring IMHO...) the last weeks, thanks for sharing those very interesting, detailed and smart steps, Reg.