# Migrating to Cronofy

## Migrating Calendar Sync
One of the core things that you will need to do is to migrate the authorizations from your existing provider apps or provider to Cronofy. This will require each user or company IT admin to authorize via the Cronofy hosted authorization flow.

If your application is in production then we would recommend running both connection approaches side by side to ensure that the migration process is as smooth as possible for your users.

When everyone has authorized through Cronofy you can quietly deprecate the other provider.

### Modelling Multiple Authorizations
You are likely already holding credentials per user in your application. If they support OAuth2 it likely looks something like this.

```mermaid
classDiagram
  User : id
  User : ...
  User : provider_user_id
  User : provider_access_token
  User : provider_refresh_token```
You should extend your User object to include Cronofy credentials alongside.

```mermaid
classDiagram
  User : id
  User : ...
  User : provider_user_id
  User : provider_access_token
  User : provider_refresh_token
  User : cronofy_sub
  User : cronofy_access_token
  User : cronofy_refresh_token```
Alternatively if you're using a [factory pattern](https://en.wikipedia.org/wiki/Factory_method_pattern) with identifiers for the different provders, you can just introduce a `cronofy` provider to your factory and store that value in your `provider_id` field or equivalent.

```mermaid
classDiagram
  User : id
  User : ...
  User : provider_id
  User : provider_user_id
  User : provider_access_token
  User : provider_refresh_token```
### Authorizing Users With Cronofy
At this stage it is worth reading through the [Authorization docs](/developers/authorization/index.md) to familiarize yourself with the differences between [Individual Connect](/developers/authorization/individual-connect/index.md) and [Enterprise Connect](/developers/authorization/enterprise-connect/index.md).

The result of both authorization approaches is values for the `cronofy_sub`, `cronofy_access_token` and `cronofy_refresh_token` that you can store against your User record.

### Using the Correct API Provider
In your existing code you will have functions that interact with the API provider. The task now is to make sure that you use Cronofy once your Users have authorized.

If you're already using a factory pattern then just creating a concrete class that handles the Cronofy interactions with the same interface as your existing other classes should give you what you need.

If you have only had one provider then you need to organize your code such that you switch to a different API when your User has a value for `cronofy_access_token`.

This could be as simple as an `if` statement at the appropriate point. Alternatively, the [factory pattern](https://en.wikipedia.org/wiki/Factory_method_pattern) is well suited to these kinds of programming tasks.

## Migrating Scheduling

---
[Read in HTML](/developers/getting-started/migration-to-cronofy/)