Microsoft 365 Tenant Migration and Keka SSO: What You Need to Know

Overview

When organisations consolidate multiple Microsoft 365 tenants into a single tenant, employees who use Microsoft Single Sign-On (SSO) to access Keka may wonder whether their login access, employee profiles, or historical records will be affected.

In most cases, Keka continues to function normally after the migration. However, there are a few important considerations depending on the type of Microsoft SSO configured in your organisation.

 

Does a Microsoft 365 Tenant Migration Affect Existing Keka Logins?

Generally, no action is required on the Keka side when migrating Microsoft 365 tenants.

Keka's standard Microsoft (Office 365) SSO is not tied to a specific Azure AD tenant for each domain. If employees continue using the same email address after the migration, they can continue signing in to Keka with Microsoft SSO without any additional configuration.

This applies whether your organisation is merging a few domains into a single tenant or consolidating multiple subsidiary tenants into a parent tenant.

 

What Happens to Employee Profiles and Historical Data?

A Microsoft 365 tenant migration does not affect employee records stored in Keka.

The following data remains intact:

• Employee profiles
• Attendance records
• Leave history
• Payroll data
• Documents
• Performance records
• Other HR information stored in Keka

Employee data continues to remain associated with the same Keka account

 

How Are Migrated Users Mapped to Their Keka Accounts?

Keka automatically maps users during Microsoft SSO login based on their email address.

For this mapping to work successfully:

✅ The employee's primary email address or User Principal Name (UPN) must remain exactly the same after migration.

If the email address or UPN changes during migration, Keka will be unable to match the user with the existing account, and the employee may encounter login issues until the mismatch is corrected.

Recommendation

Before starting the migration, confirm with your Microsoft 365 administrator that employees' primary email addresses and UPNs will remain unchanged in the destination tenant.

 

Will Tenant Migration Create Duplicate Employee Profiles?

No.

As long as employees continue using the same email address and UPN, Keka will continue to associate them with their existing accounts and no duplicate employee profiles will be created.

 

Do You Need to Reconfigure SSO in Keka?

The answer depends on the Microsoft SSO method configured in your organisation.

Basic Microsoft (Office 365) SSO

Reconfiguration Required: No

This configuration uses Keka's shared Microsoft sign-in application and is not tied to your organisation's specific Azure AD tenant. Tenant migrations typically do not require any changes within Keka.

Custom Active Directory OIDC (Microsoft Entra ID) SSO

Reconfiguration Required: Yes

This configuration stores organisation-specific Microsoft Entra ID details such as:

• Tenant ID
• Client ID
• Client Secret

If your Microsoft Entra tenant changes, you must:

• Create a new Enterprise Application in the destination tenant.
• Update the Tenant ID, Client ID, and Client Secret configured in Keka.
• Complete this update before the old tenant is decommissioned to avoid login disruptions

 

How to Check Which SSO Type Your Organisation Uses

Navigate to:

Settings > Integrations and Automations > Authentication

If you're unsure about the configuration, contact your Keka support representative.

 

What Should Be Verified on the Microsoft 365 Side?

Regardless of the SSO type being used, ensure that the destination Microsoft Entra tenant has appropriate consent for Keka's sign-in application.

Because app consent is granted at the tenant level, the destination tenant may require administrative approval before users can authenticate through Microsoft SSO.

If consent has not already been granted, a one-time administrator approval may be required after migration.

 

Pre-Migration Checklist

Before migrating Microsoft 365 tenants, verify the following:

• Employees' primary email addresses and UPNs will remain unchanged.
• The SSO method configured in Keka is identified.
• If using Custom AD OIDC or Microsoft Entra ID SSO, a new Enterprise Application is created in the destination tenant.
• Keka's Tenant ID, Client ID, and Client Secret are updated before the old tenant is retired.
• The destination tenant has admin consent approved for Keka's sign-in application.
• A pilot login test is completed with a small group of migrated users before the full migration.

 

Related Article

• Configurable SSO for Microsoft Active Directory (OIDC)

 

Need Assistance?

If you have questions about your Microsoft 365 tenant migration or need help validating your SSO configuration, please contact your Keka support representative or account manager before proceeding with the migration.