Having response time issues using Studio to manage 3000+ forms

Question

We are currently using Documaker Studio to create and maintain our forms, of which we have thousands. Once we create the form we export it to a very old version of Documerge where it is then used in our policy production. 
The problem is that because we have so many forms/sections, everytime we click on "SECTIONS" in Studio it takes a significant amount of time to load the screen that lists all of the sections. Many of these forms/sections are old and will never change but we want to still have access to them in the future.
What is the best way to "backup" all these forms somewhere where they are still accessible? Ideally I think I would like to have one workspace (let's call it "PRODUCTION") that has all 3000+ forms and delete the older resources from our existing workspace (called "FORMS") so that just has the forms that we are currently working on.  This way the response time in the "FORMS" workspace would be much better. Couple questions:
1. How would I copy my existing workspace "FORMS" (and all the resources in it) to a new workspace called "PRODUCTION"?
2. How would I delete from the "FORMS" workspace all of the older resources?
3. Once I am satisfied with a new form/section in my "FORMS" workspace how would I move it to "PRODUCTION"?
4. How could I move a form/section from "PRODUCTION" back into "FORMS" in order to make corrections, or use it as a base for a new form down the road?
5. Most importantly....Is there a better way to do this?
Again, we are only using this workspace for forms creation and not using it to generate output...we will be doing that in the future once we upgrade from the very old Documerge on the mainframe, to Documaker Studio.
Many thanks to any of you who can help me with this!

Answer 1

However, I am a little confused on the difference between extracting and promoting. Am I correct in assuming that I would go into my PROD workspace and EXTRACT the resources that I want to continue to work on. I would then go into my new, and empty, DEV workspace and IMPORT FILES (or IMPORT LIBRARY?) using the file(s) that I created with the EXTRACT? In effect, I would have two totally separate workspaces, one called DEV and one called PROD?
Extraction is writing a copy of a resource from the library out to disk. Promotion is copying a resource from one library to another, with the option of modifying the metadata values of the source and target resources. You would use extract in a case where you don't have access to both libraries to do a promote.
An example promotion scenario would go something like this. You have resources in the source (DEV) that you want to promote to the target (PROD). Items to be promoted are tagged with the MODE = "To Promote". When you perform the promotion, you can select the items that you want to promote with the filter MODE="To Promote". When you perform the promotion, you can also configure Studio to set the MODE of the resource(s) in the source to be MODE="To Delete", and set the MODE of the resource(s) in the target to be MODE="" (empty). Then you can go back and delete the resources from the source (DEV) where MODE=DELETE.
Once you have the libraries configured you could bypass the whole extract/import bit and just use promote. The source would be PROD, and the target would be DEV. During promotion, set the target MODE = "To Do", and source MODE = "In Development". In this fashion you will see which resources in PROD are currently being edited in DEV (because in PROD the MODE = "In Development"). When development is completed, change the MODE in DEV to "To Promote", then proceed with the promotion scenario described above.
I am a bit confused on the PROMOTE function and the libraries that have the  _DEV _TEST _PROD suffixes. This looks like it duplicates the entire workspace to new libraries _PROD but it is all part of the same workspace, not two separate workspaces?  Any clarification here would be helpful.
Those suffixes are just attached by default; these suffixes don't mean anything to Documaker. You could name your library PROD and use it for DEV. It might be confusing though ;-) The usual best practice is to name the library and subsequent tablespaces/schemas according to their use. It's possible to have multiple libraries within a single tablespace or schema (but not recommended to mix PROD and non-PROD libraries).
Getting there, I think!
-A