Here the details for the PEGA platform related tables
pc_data_uniqueid table corresponds to the Data-UniqueID class, and contains a single row for each work item ID format in use.
A scheduled report is a work item (of work type Pega-ScheduledTask ), with prefix PX-ST-, saved in the database table pc_schedule_task
Many wizards and developer tools available in the Designer Studio — for example, the Product Migration wizard — are implemented as screen flows and create work items in your system. The work types of such work items start with PegaAccel-Task-.
The PegaAccel-Task- class is mapped to the pc_work_accel database table. This ensures that work items produced by developer tools are saved in a dedicated table separate from work items from business applications. Such separation improves reporting performance.
Pulse messages will be stored in pc_work_social table
Operator id instances used for loging to application
Contains one row for each rule delegation, corresponding to instances of the System-User-MyRules class.
Pega OOTB stores Regular and Occassional Users information Monthly Wise in the OOTB Table pr_usage_summar
You can skip merging of pr_log,pr_daily_usuage and PR_USAGE_SUMMARY tables as they are performance stats and logging related tables.
PR_DATA_DMS_CUSTOMER_DATA,PR_DATA_DMS_DEVICE,PR_DATA_DMS_PURCHASE and PR_DATA_DMS_SUBSCRIPTION are related to Pega DMSample application you can query the table based on pxobjclass. This sample data would already be available in target pega 7.4 and can be ignored.
Contains the data instance of operators used to login to application. if the operators logging into both the applications are unique then you would not have any problem in merging them. however, if the same operators login and use both the applications then you can skip merging at table level and just write an activity to update the accessgroup reference for the new application to existing operators.
Are the work id prefix same or different for both the applications? This is very important table which helps pega platform to determine the next work item id to be assigned based on the pyprefix.
You would have to analyze the data on both the source and target environment and perform the merge.
If you already have the application deployed and instances related to Data-Admin-Nodes"
are already available then you dont have to merge this table. Rather use Product rule to package the specific instance not available and import them
Details on other tables are already mentioned above. you would be in better position to make a call on what is required for your application to function and perform selective move based on the data already available in pega 7.4 application you are performing on to.