# Property terms migration
## Strategy
We will migrate proeprty terms from `wb_terms` table (old) into the new schema tables (new)
following the usual migration plan:
1. read old, write old
2. read old, write both & run maintenance on all Properties
3. read new, write both
4. read new, write new
## Estimations
* Demand on extra disk space will be below 20MB for the whole thing.
* Maintenance script is estimated to execute in matter of few minutes.
* No risk on read performance degradation as we will switch to reading
from new right after maintenance script is finished, and probably also
stop writing to new the next day.
# Item terms migration
## Strategy
To avoid a very big extra disk space needed when we start migrating item terms,
as well as a risky overhead on read performance, we will do this in a slightly modified
version of the usual process (the one we follow above).
1. read old, write both - run maintenance on Q1-Q2mio terms (the most accessed ones)
2. read one, write both (timeboxed for 2 weeks to monitor performance)
3. read one, write new (until we have new master with higher capacities)
4. run maintenance on all items
5. read new, write new
where:
* `read one` means programmatically decide which schema to read from based on item id.
* run maintenance here will always be done in batches/iterations.
## Estimations
* In step 1, we migrate 10% of items to the new schema in order to reduce the extra disk space needed after step 1, which should be around **17GB**.
* We also greatly reduce the risk of performance degradation on reads as we will determine which schema to read from on application level and avoid reading from both always.