# Ingram BookBuilder v3 Launch Planning

## Options to discuss

### 1. Run apps in parallel for a short period

We would run both apps in parallel for a period of time. Any new titles created would lead users to the v3 app. Any existing title not yet completed would lead users to the v3 app. We notify v2 users to complete their build by a certain time and maybe give them an option to upgrade and start over on the v3 platform.

Create some middleware on the bookbuilder side that can figure out if the title is new or old - use create date and see if we have a record in v2.

**Advantages**

- Simplicity of no data migration and bugs/issues/support related to that
- Doesn't confuse the users who are in the middle of building their book on v2
- Don't have to make users rebuild their active v2 covers from scratch

**Disadvantages**

- We have to run both systems at once, but can probably scale down v2 support to lessen the cost for the period before we shut it off completely
- A bit more integration to ensure the button in the spark title setup drives to the correct app

### 2. Data migration and single cutover

We would undertake the effort to map and migrate v2 data into our v3 databases. Spark dashboard links could then be updated to point at the new system. Because cover data cannot be mapped 1 to 1, we would need to define a plan to have users that have not completed books to rebuild thier covers.

**Advantages**

- Easier integration on spark side to just change the domain the book builder button points too
- Can turn v2 off sooner

**Disadvantages**

- Complex data migration
- Cover data cannot be replicated in new system due to new layout structure
- Time to migrate and test this takes away from time we would solely focus on v3 testing and deployment

## Odyssy suggestion

**Option #1**

- Run in parallel for 3 months
- Explore an option to allow user to download raw content from v1 and import to v2
- If there is some kind of requirement by spark TOS, keep an offline version of the db where users can request the exports into the future (like through a form/email)

## Other considerations

#### User Notification
- In app (v2) messaging/banner to notify users of upcoming change
- Email notification to users who have books in progress
- Walkme?

#### Analytics to help us decide?
- Can we find out how many users might have started books that are not approved?

#### Content download/upload
- It might be necessary to develop one off solutions for preserving data going into the indefinite future.
- We may need some way for a support person to export internal content through a one off job/processes. This export may be a ebook, or a HTML file of content. It's probably assumed that most users have a backup as their original Word file already.