The current environment is a consolidated database replicating to 34 remote databases. During migration a full extract of the consolidated database will be made and converted to ASA 12. This ASA12 consolidated database will replicate with the ASA 8 consolidate database for the entire migration period. When the last remote database is converted to ASA 12 and the last application rewrite is completed the ASA 8 consolidated database needs to be decommissioned and the ASA 12 database needs to become the only consolidated database. My question is what do I need to do, to complete this final step? My first thought was that all I had to do is go to the SQL Remote property page and uncheck ‘This database has as corresponding consolidated database” and stop running the dbremote process the synced the ASA 8 consolidated to the ASA 12 Consolidated Is this correct or are there more things I need to do? I need the two consolidate database to support applications that only run in this environment that will be being rewritten. This configuration also allows easy fall back to the old environment if any issues arise.
[Note: This is gonna be a counter-question, not an answer...]
Is there really no possibility to migrate the cons from v8 to v12, and then use the v12 db as the only consolidated - and then migrate remotes lateron?
I've lately done that (after very thorough testing, obviously), and would think it is much easier than your plan.
Part of the my task was to make sure all related apps run with v8 and v12 unchanged or have to be changed (in a few cases, fortunately) to run with both. That included a few program updates and a few modifications in the database, say, by using STPs in v8 and v12 with minor differences.
Another part were intense tests to make sure SQL Remote works with both versions, because - as you state - I won't be able to go back to a v8 cons without having to re-extract some hundred remotes (which is a no-go, apparently): Migrating the v12 cons back to v8 would be doable with some effort, but the v12 logs created in the meantime won't be readable by the v8 software making the necessary log scans impossible.
Making tests with some v12 remotes in the production system were a third part - partly becuase the risk to re-extract those was affordable.
So, in a way, I have done that "month-long migration period" on test systems before the real migration of the consolidated - omitting a month-long migration there.