Restructure App Hierarchy with Data In Place

Depending on the reports and pipelines you may need to change a lot of it. Lookup fields are easy because they can be pointed to a new field, but summary fields would need to be changed too. 

I would probably start by making the new relationships. Getting the proposals created on the opportunities. Then Linking the orders to the proposals. Then I would look at the fields you need to pass from opportunities to orders and get those set up and transferred. Get the reports realigned, then work on the pipelines. 

In the meantime you could make the related field between opportunities > orders a formula that points to the proposals table related opportunity. It's going to be a bit of a painful process. I've done things like this before. Eh...I DO things like this. A lot. I took over this position in December of last year, and I'm still fixing things and restructuring things.

------------------------------
Dwight Munson
------------------------------

Hey Ivan,

I feel your pain! 

Thankfully QB offers some pretty nice tools that you may be aware, but are worth mentioning:

• In App Management you can Show Relationship Diagram, I'd make sure to tidy and study.
• In a given Relationship, you can see the fields involved on both sides (the Parent Summaries and the Child Lookups and foreign key)
• On a given field you can see the Usage and Dependencies
• The Usage provides links in which you can repeat the process to again view Usage and Dependencies.
• The Dependencies provide a field ID, which you can manually key into the URL to more quickly navigate (since they are not linked)

With these tools, we need to basically go through each impacted field. One convention is to prefix fields that you'll be deprecating with a lowercase letter "z" instead of deleting them. But be careful as renaming fields could potentially break other processes such as Pipelines or API calls (typically not the latter when referenced by FID). For example, if you had a "Name" field that would become "zName" to indicate you have assessed the field and it's no longer necessary. This is nice when sorting fields by too (to shuffle them to the bottom of the list).

Or you can try to kinda hijack lookup fields instead of deprecating them, by changing their name the value they point too. But I typically wouldn't use this "sleight of hand" technique  in larger refactors (such as this one) and instead I'd try to keep the old system in place until the new system is build in parallel.

Then, once you tested everything you can delete the older relationships and "z" fields.

Also, worth mentioning is Quickbase keeps backups of your app that you can request if necessary. But you can also copy an app with its data if you want to create a playground to test the new architecture first. There is also Sandbox functionality too!

Also, you could potentially leverage Access Permissions to disable viewing, adding, and editing of records in the older tables before deletion to make sure there are no issues.

Anyway, there is no simple answer. Just plan it out and then methodically flag and eliminate the older fields and relationships. You've got this ;)

------------------------------
Brian
------------------------------