Update README.md (#301)

docs/README.md

@@ -17,7 +17,8 @@ This document is intended to describe how the data model for various items in th
   subAreas: [
     {
       name: <subAreaName>,
-      id: <subAreaId>
+      id: <subAreaId>,
+      isLegacy: false
     }
   ], // map list of subareas within the park
 }
@@ -59,7 +60,9 @@ You can get a list of subareas and their ids for a particular park using the [pa
 
 ## Configs
 
-Each subarea will have 1 config object per `activity`. Configs are used to establish modifiers for all activities within the subarea independent of time.
+Each subarea will have 1 config object per `activity`. Configs are used to establish modifiers for all activities within the subarea independent of time. 
+
+When a new activity record is created, the relevant config object is used as a starting template. In other words, an activity object is in part a snapshot of a config for a particular month.
 
 You can get a list of all the configs within a subarea by looking at `activities` in the [subareas](#subareas) structure above.
 
@@ -223,3 +226,58 @@ Variances track differences in activity field record values from year to year. T
   ] // list of fields that have triggered a variance and what that variance is
 }
 ```
+# Legacy Data
+
+BC Parks attendance and revenue data was previously tracked in an Excel document containing data that can be traced back to the year 2000. A modernized replacement system was proposed to track these data.
+
+The MVP for the modernized A&R System included the creation and management of monthly activity records for subareas within umbrella of parks run by BC Parks. MVP included considerations for the following activities:
+
+* [Backcountry Cabins](#backcountry-cabins-activity-record---specific-fields)
+* [Backcountry Camping](#backcountry-camping-activity-record---specific-fields)
+* [Boating](#boating-activity-record---specific-fields)
+* [Day Use](#day-use-activity-record---specific-fields)
+* [Group Camping](#group-camping-activity-record---specific-fields)
+* [Frontcountry Cabins](#frontcountry-cabins-activity-record---specific-fields)
+* [Frontcountry Camping](#frontcountry-camping-activity-record---specific-fields)
+
+Each collected property related to one of the above activity categories. You can view the specific properties by reviewing the [Activity Records](#activity-records) section.
+
+## Migration of legacy data
+
+When it came time to migrate over the existing data from the Excel document, it was discovered that though most of the properties in the Excel document related to one of the above activity categories, not all of them were already captured by the data model schema that the modernized system currently enforced. Furthermore, there were a handful of properties that did not relate to any existing activity. This meant there was an incongruency between modern data that the new A&R system was collecting and the legacy data contained within the Excel document. This left a handful of complicated options available to proceed with the migration of legacy data:
+
+* Adapt the data model currently in-use by the modern A&R system to use the exact data model from the Excel document. This was not favorable as it required both a large migration and fundamentally changing the already-functioning system, introducing significant risk. Furthermore, the exact data model of the Excel document could not be decided as there were inconsistencies within the Excel data itself.
+* Only migrate over properties from the Excel document that could be definitively 1:1 mapped to properties in the modern system. This also was not favorable as it involved discarding a large portion of Excel data, and making assumptions on which historical property mapped to which modern property, compromising what integrity the Excel data had.
+* A hybrid implementation of the first two options, where properties that could be definitively 1:1 mapped were brought over into the modern system, and new properties were created where mapping fell short. Each migrated record would be flagged as `isLegacy` for quick identification in the event we needed to separate historical data from modern data. 
+
+Proceeding with the hybrid implementation, a new activity was introduced exclusively for migrated activity records that captured any property that did not fall into an existing activity category:
+
+* Legacy Data
+
+See [#237](https://github.com/bcgov/bcparks-ar-api/issues/237) and [#680](https://bcparksdigital.atlassian.net/browse/BRS-680) for more.
+
+## Differences in modern and legacy data
+
+The fundamental rule about migrating the legacy Excel data was this: "If the legacy data changes in any way, it is no longer legacy". In other words, once a party alters migrated data from how it is originally defined in the Excel document, that party assumes responsibility for the altered data's integrity and reliability. Several steps were taken to ensure the modern A&R system could be used as a source of truth for legacy data without altering the integrity and reliability of the original Excel document.
+
+Initially, all data with an `isLegacy` flag was locked against editing.
+
+### Parks
+
+It was assumed that all parks that would continue to collect attendance and revenue data were present in the modern A&R system before migration. Therefore, any park present only in the migration would be created in the modern system with an `isLegacy` flag.
+
+As later determined in [#250](https://github.com/bcgov/bcparks-ar-admin/issues/250), parks that were created as as `isLegacy` still may collect attendance and revenue data. 
+
+### Subareas
+
+It was assumed that all subareas that would continue to collect attendance and revenue data were present in the modern A&R system before migration. Therefore, any subarea present only in the migration would be created in the modern system with an `isLegacy` flag.
+
+Later, it was requested that some of these subareas get reopened for collecting attendance and revenue data again. Instead of removing the `isLegacy` flag on the subarea, it was decided in these cases a new subarea would be created using the modern A&R system and further attendance and revenue data would be recorded under the modern subarea. This prevents us from alterning legacy subareas. 
+
+All legacy subareas include the `Legacy Data` activity regardless of whether the subarea has data in that category. 
+
+## Configs
+
+There are no config objects for legacy activities, as there is no need for an activity template. The modern A&R system will never create a modern activity record from a legacy config.
+
+