OpenLDAP vs 389 Directory Server: which to choose

OpenLDAP vs 389 Directory Server: when each one fits a new directory

If you are standing up or replacing a central LDAP directory, you are choosing between two general-purpose open-source servers, and the choice rests on a few concrete drivers. Choose OpenLDAP when you want a complete LDAPv3 server built around slapd, the MDB backend, overlays and a 2.6 long term support line, and when your team is comfortable editing slapd configuration and maintaining it as a conventional Linux service. Choose 389 Directory Server when you need multi-supplier replication for fault tolerance and high write performance, when schema, configuration and access controls must change online without downtime, or when your estate is built on Red Hat or Fedora and you want management through dscreate, dsctl, dsconf, dsidm or the Cockpit console. Neither choice is wrong by default; the decision follows from the four drivers below.

Start with replication topology, because it is hardest to change later. Map where your writes must land, how many sites hold a writable copy and how failover should behave, then check that the design you need is supported by the server you pick. Next, check platform packaging. Red Hat removed the OpenLDAP server package in RHEL 8, and the Red Hat RHEL 8 adoption guide lists that removal, so confirm which packages your target operating system ships and whether your support contract covers a self-built server. Third, inventory existing data. The 389 migration tool, openldap_to_ds, moves schema, indexes, backends, data and some overlays, but OpenLDAP-to-389 replication, LDAP proxy, AD synchronisation and TOTP are not compatible and need redesign, so list every integration that depends on them before you commit. Fourth, assess your team's skills and the cost of running the directory over several years; ask any implementation partner to price these items in a written scope.

Which directory fits which scenario

This table maps common directory scenarios to the better fit between OpenLDAP and 389 Directory Server, with the reason and the condition that would reverse the choice. Read each row against your own requirements, and confirm the items flagged for vendor or environment checks before committing.

Scenario	Better fit and reason	When the other option wins
Greenfield directory on Linux with a small admin team	389 Directory Server, because dsctl, dsconf and dsidm give one consistent command set for instance creation, backups and identity content, and the Cockpit console adds a web view. Schema and ACI changes can be applied online through LDAP operations.	OpenLDAP wins if the team already knows slapd configuration and wants the MDB backend, overlays and lloadd in one familiar stack. Confirm the admin tooling you will use day to day.
Multi-site deployment needing writes at more than one server	389 Directory Server, because it provides asynchronous multi-supplier replication aimed at fault tolerance and high write performance. Test conflict handling against your own write patterns before go-live.	OpenLDAP wins if your design can tolerate a single writable provider with consumers, or if you need its multi-provider replication and proxy features. Confirm the replication topology and conflict behavior in the OpenLDAP 2.6 Administrator's Guide for your version.
Red Hat or Fedora estate that already runs FreeIPA	389 Directory Server, because FreeIPA uses it as its multi-master LDAPv3 directory for users, groups, hosts and policies. Running the same directory engine keeps operations and skills consistent.	OpenLDAP wins only if you have a specific application that requires OpenLDAP overlays or behavior and you accept a second directory. RHEL 8 removed the openldap-servers package, so confirm package availability on your RHEL release before planning.
Migration from an existing OpenLDAP server	389 Directory Server with openldap_to_ds, because the tool migrates custom schema, indexes, backends, data from slapcat LDIF exports and some overlays on a best-effort basis. Plan a test run first.	Stay on OpenLDAP if your deployment depends on OpenLDAP-to-389 replication, the LDAP proxy, AD synchronisation or TOTP, since the migration guide says these are not compatible and need redesign. Confirm each dependency in a lab before choosing.
Application-heavy estate needing overlays or a caching proxy	OpenLDAP, because slapd supports overlays and can act as a caching LDAP proxy, and the 2.6 line is a long term support release. Check each application's required overlay against your version.	389 Directory Server wins if your applications only need standard LDAPv3 operations, TLS and SASL, and you want online configuration changes without restarts. Confirm which overlays your applications rely on, because the migration tool covers only some of them.
Long-term support and version planning	OpenLDAP, if you want the 2.6 LTS line with a documented support window. Confirm the current support dates with the OpenLDAP Project before standardizing.	389 Directory Server suits teams that track the 3.x release lines closely and are comfortable with the GPLv3 license. Confirm the support model that your distribution or vendor provides.
Directory must hold Windows domain services	Neither option replaces Active Directory on its own, so confirm the requirement before choosing a Linux directory. FreeIPA can establish a cross-forest trust with an AD domain for Linux resources.	A mixed estate that needs Windows domain join or Group Policy keeps Active Directory, and either LDAP server can sit beside it for Linux applications. Confirm trust and sync design with your AD team.

How OpenLDAP slapd and 389 Directory Server are built and run

Both servers implement LDAPv3 and both can hold a central directory, but they differ in how they store data, replicate changes and get administered. The cards below cover the parts that shape daily work: where configuration lives, how writes spread between servers and which tools your team will use every week.

slapd and the MDB backend

slapd is OpenLDAP's stand-alone directory server, and its main database backend is MDB, a hierarchical transactional store built on LMDB. For day-two work, the admin team edits slapd configuration and manages schema and indexes directly, so the team needs to be comfortable with OpenLDAP's own configuration model. Confirm which OpenLDAP line (2.7.1 feature or 2.6.15 LTS) your support plan covers before you standardize on it.

Overlays and the caching proxy

Overlays add behavior to a slapd database, and slapd can also act as a caching LDAP proxy in front of other directories. These features extend what OpenLDAP does, but each overlay adds configuration that someone must test after upgrades. When you migrate with openldap_to_ds, check which of your overlays are covered, since 389 Directory Server only converts some of them on a best-effort basis.

lloadd as a separate load balancer

lloadd is a stand-alone LDAP load balancing proxy that ships with OpenLDAP 2.7. It is a separate daemon, so it has its own configuration, service lifecycle and monitoring to manage alongside slapd. Teams that already run a load balancer may prefer to keep that role there, while teams without one should check whether lloadd fits their topology before adding another component.

389 Directory Server multi-supplier replication

389 Directory Server provides asynchronous multi-supplier replication, so several servers can accept writes and exchange changes. This suits designs that cannot accept a single point of failure, but it also means your team must plan conflict handling and monitor replication lag between suppliers. Ask the vendor or your own tests how conflicts are resolved for your data model before you rely on multiple write paths.

dscreate, dsctl, dsconf and dsidm tooling

389 Directory Server instances are created with dscreate and managed with dsctl for local start, stop and backups, dsconf for local or remote configuration, and dsidm for identity content. Schema, configuration and ACIs can be changed online through LDAP operations without downtime. Administrators need to learn this command set, and they should decide which changes go through version-controlled scripts and which are made interactively.

Cockpit console for administration

389 Directory Server offers a Cockpit web console as an alternative to the command line. It can help operators who prefer a graphical view of instances, but the console does not replace the need to understand dsconf and dsidm for scripted or remote work. Check whether your operations team will use the console for routine tasks, and whether its access controls match your privileged access policy.

OpenLDAP vs 389 Directory Server: capabilities side by side

This table sets OpenLDAP's slapd against 389 Directory Server on the capabilities that matter when choosing a general-purpose LDAP directory. Read each row as a question to confirm against your own requirements, especially replication topology, tooling and packaging on your target distribution. The main takeaway is that the two differ most in replication design, online administration and how each is packaged and supported.

Capability	OpenLDAP (slapd)	389 Directory Server
License	OpenLDAP Public License, described by the project as non-restrictive and free and open source	GPLv3 for code, CC BY-SA 4.0 for documentation
Current release lines	Feature release 2.7.1 and long term support release 2.6.15	389-ds-base 3.3.1, 3.2.3 and 3.1.5, all released September 7, 2026
LDAPv3, TLS and SASL	LDAPv3 over IPv4, IPv6 and Unix IPC, with SASL and TLS certificate authentication	LDAPv3 compliant, with TLS and SASL support
Main storage backend	MDB, a hierarchical transactional backend built on LMDB	Confirm the backend and database layout for your version in the 389 Directory Server documentation
Replication model	Single-provider, multiple-consumer and multi-provider replication for environments that cannot accept a single point of failure	Asynchronous multi-supplier replication for fault tolerance and high write performance
Overlays and proxy role	Overlays supported, and slapd can act as a caching LDAP proxy; lloadd is a separate load balancing proxy	Some overlays are carried over by openldap_to_ds on a best-effort basis; confirm overlay coverage for your design
Online configuration changes	Confirm which settings your OpenLDAP version applies without a restart before planning changes	Schema, configuration and access controls can be updated online through LDAP operations with zero downtime
Scale statements from port389.org	Not stated in the supplied facts; ask for sizing guidance for your data volume	Database size limited only by disk space, and the project says it handles hundreds of thousands of accounts
Management tools	Command line LDAP utilities, LDIF tools and slapd configuration files	dscreate, dsctl, dsconf and dsidm for instance creation, local control, configuration and identity content
Web console	No web console is part of OpenLDAP; confirm any third-party interface you would add	Cockpit web console available
Package availability	Confirm packaging on your distribution, since Red Hat removed openldap-servers in RHEL 8	Installs as 389-ds on openSUSE Leap 15 and Tumbleweed, and as 389-ds-base on Fedora and CentOS 8

Licensing and editions: what each project publishes

OpenLDAP Software is available under the OpenLDAP Public License, which the project describes as a non-restrictive, free, open-source license. The software is developed by the OpenLDAP Project, a team of volunteers, as an organized activity of the OpenLDAP Foundation, and it is derived from University of Michigan LDAP release 3.3. For licensing purposes, that means you can review the licence text, build the server yourself and deploy it without a per-server fee from the project. The project publishes two release lines that matter for planning. The current feature release is 2.7.1, and the current long term support release is 2.6.15. OpenLDAP 2.7 retired the back-sql and back-perl backends and deprecated the GnuTLS integration, so teams with those dependencies should treat 2.7 as a migration decision rather than a routine upgrade.

Licence terms: The OpenLDAP Public License is permissive. Read the licence text itself with your legal team before you embed or redistribute builds.
Feature line: 2.7.1 is the current feature release. It includes slapd, lloadd, client libraries, LDIF tools and command line utilities.
LTS line: 2.6.15 is the long term support release. Choose it when you need a stable line with a longer planning horizon, and confirm its support window with the project.
Removed components: The back-sql and back-perl backends are retired in 2.7, which matters if your directory depends on them.
Support model: The supplied facts do not document a paid OpenLDAP edition or commercial support contract. Confirm any support arrangement directly with the project or with a vendor you choose.

Before you commit, confirm which release line your distribution packages and whether your vendor will support it.

Why Red Hat's removal of openldap-servers in RHEL 8 changes the choice

If your estate runs Red Hat Enterprise Linux, the first question is not which LDAP server is better in the abstract but which one you can install, patch and get support for from Red Hat's own repositories. Red Hat's guide to adopting RHEL 8 lists openldap-servers among the packages removed in RHEL 8, and notes that the package is not present in RHEL 8.1 to 8.5. For a Red Hat shop, that removal means the OpenLDAP server is not a default option you can simply carry forward from an older build. It shifts the decision toward 389 Directory Server, which Red Hat packages as part of its identity stack through FreeIPA, or toward a self-built OpenLDAP that your team owns end to end.

The practical consequences fall into three areas. Patching: if you run slapd from a source build or a third-party repository, your team owns the security fix cadence, the rebuild of modules and overlays, and the testing against your schema. Vendor support: a server outside Red Hat's packaged set is not covered by the same support path, so you should ask Red Hat in writing what it will and will not support on the exact RHEL release you run. Supported stack: if an auditor or internal architecture review asks which directory is supported by your platform vendor, the answer should come from the vendor's current documentation, not from memory of an older release.

Before committing, confirm the following with Red Hat and in your own environment: whether openldap-servers or any OpenLDAP server package is available for your exact minor release, which repositories and subscriptions are required, and whether 389 Directory Server or FreeIPA packages cover the functions you need. Check the Red Hat adoption guide for the RHEL 8 package changes, then verify the current state for your release rather than assuming the 8.1 to 8.5 window still describes your options.

Moving an existing OpenLDAP directory to 389 Directory Server

This sequence takes an existing slapd directory through an inventory, a rehearsal on a test host and a controlled conversion, then rebuilds the parts the tool does not carry across. The end state is a 389 Directory Server instance that has been checked against your client applications before any production cutover.

Inventory the OpenLDAP configuration and overlays
Before touching data, list everything the current slapd instance does: the backends and their database types, the schema files you have added beyond the standard ones, the indexes, every overlay in use, and any replication, LDAP proxy, Active Directory synchronization or TOTP arrangements. The migration how-to states that replication, proxying, AD synchronization and TOTP are not compatible with the conversion, so this inventory decides which items will need redesign. The owner of the directory and the application owners should sign off on this list. It is done when each overlay and integration is marked either as expected to transfer or as a rebuild item.
Export data and schema from the source
Take a consistent export of the directory data with slapcat, producing LDIF files, and copy the slapd.d configuration directory in LDIF format. Keep the original server untouched and record the date, the OpenLDAP version and the file checksums alongside the exports. The conversion tool works from these exports and the slapd.d configuration, so an incomplete export becomes an incomplete directory. It is done when the exports can be read back and the entry counts match what the source reports.
Rehearse the conversion on a test host
Install 389 Directory Server on a non-production host and copy the exports and slapd.d configuration to it. Run openldap_to_ds as root or as the dirsrv user on that host, without the confirmation flag first, and read what it reports about the schema, indexes, backends and overlays it can process. The tool is documented as best-effort, so expect some items to be skipped or flagged rather than converted. It is done when you have a written list of every item the rehearsal did and did not carry across.
Run the conversion with confirmation after review
Once the rehearsal output has been reviewed by the directory owner, run openldap_to_ds again with --confirm, because the tool takes no action without that flag. Run it only on the first instance in the 389 topology, since the tool is needed only there and additional instances receive their data through replication. Keep the console output and the resulting configuration as evidence of the conversion. It is done when the first instance starts, responds to LDAP queries and matches the entry counts from the export.
Rebuild the integrations that do not transfer
Recreate OpenLDAP-to-389 replication using 389 Directory Server's own multi-supplier design, configure any LDAP proxy in front of the directory, rebuild Active Directory synchronization and reimplement TOTP enrollment, since the migration documentation says these need redesign. Confirm the exact replication and proxy settings against the 389 Directory Server documentation and your own topology, not against the old slapd files. It is done when each rebuilt integration has a written design that the owner has approved and a test showing it works on the new instance.
Re-test client applications against the new directory
Point each application that binds to the directory at the 389 instance in a test environment and run its login, group lookup, password change and account provisioning paths. Check TLS and SASL bind methods, search base DNs, attribute names and any schema extensions the applications rely on. Document each failure and its fix. It is done when every application has a signed-off test record covering its normal authentication and directory operations.
Cut over and keep the source for rollback
Schedule the cutover window with the application owners, freeze directory changes on the source, take a final export, apply any delta to the 389 instance, and switch client configuration to the new hostname or address. Keep the original OpenLDAP server available in read-only mode until the business owner accepts the result. Ask your 389 Directory Server support provider or internal platform team to confirm the rollback steps in writing before the window opens. It is done when all clients authenticate against the new directory and the rollback plan has been tested or explicitly accepted as untested.

What drives the running cost of each directory

Running cost for either directory comes from a handful of recurring and one-time components: the servers and replication design, the people who operate them, the support you buy, the upgrade cadence, the migration or rebuild, and the applications that bind to LDAP. Scope each one in writing before comparing totals, because the same component can cost very different amounts under OpenLDAP and 389 Directory Server.

Server infrastructure and high availability

Both servers can run as a single provider with consumers or as multi-supplier replicated pairs, and the number of nodes you run for availability is the largest recurring hardware and hosting line. OpenLDAP's slapd supports single-provider multiple-consumer and multi-provider replication, while 389 Directory Server provides asynchronous multi-supplier replication. Ask the vendor or integrator to show the node count, the site layout and the storage sizing for each design, and whether the proposal includes monitoring for replication lag.

Staff skills and training

Your own engineers or the integrator's staff are paid for configuration, troubleshooting and on-call time, and this is usually the recurring cost that is hardest to see in a quote. OpenLDAP is configured through slapd.d and overlays, while 389 Directory Server adds dscreate, dsctl, dsconf and dsidm plus a Cockpit console. Confirm which tooling your team already knows, and ask whether training or handover documentation is in the written scope.

Support options and contracts

Commercial support is a recurring subscription or retainer that you buy from a vendor or a services firm, and it is separate from the open-source license cost, which is zero for both products. Check the support window for each release line, the response commitments in the contract, and whether it covers the directory itself or only the operating system package. DeployOpen offers ongoing support as a retainer, so ask for the scope, deliverables and response expectations in writing.

Upgrade and patch effort across release lines

Each directory moves across release lines at a different pace, and every upgrade consumes engineering time, testing and change approvals. OpenLDAP publishes a feature release line and a long term support line, so you choose which one to track and how often to move. For 389 Directory Server, confirm which branch your distribution packages and how patches reach your RHEL, Fedora or openSUSE hosts. Ask for an upgrade plan with a test environment and a rollback procedure.

Migration and rebuild work

If you already run OpenLDAP, moving to 389 Directory Server is a one-time project, and the openldap_to_ds tool only covers part of the work. It migrates custom schema, indexes, backends, data and some overlays, but OpenLDAP-to-389 replication, LDAP proxy, AD synchronisation and TOTP need redesign. That redesign and the parallel run are where most one-time cost sits. Ask the integrator to list every feature in your current setup that the tool cannot move and to price the rebuild for each one separately.

Integration work for LDAP-bound applications

Every application that binds to the directory, whether for login, group lookups or reporting, carries its own integration cost that recurs when the application or the directory changes. Differences in schema handling, access controls, password policy and TLS settings can force changes in client configuration. Build an inventory of bind points, service accounts and schema dependencies, and ask for a quote that covers testing each application against the chosen server, not only the directory build.

What implementing each directory involves and where projects run long

An OpenLDAP build starts with schema design, because the directory's object classes, attributes and indexes set what applications can bind to and search for. Next comes the slapd configuration, which in OpenLDAP 2.6 is held in the slapd.d tree, and the MDB backend sizing, since MDB is the main database backend and its map size has to be planned for the directory you expect to hold. The replication decision follows: single-provider with multiple consumers, or multi-provider replication where a single point of failure is not acceptable. A caching proxy is a separate choice. Application binds then need their own work, covering service accounts, bind DNs, TLS and SASL settings, and testing each application against the schema you actually built. Confirm the MDB sizing guidance and the replication options against the OpenLDAP 2.6 Administrator's Guide for the release you plan to run.

A 389 Directory Server build begins with instance creation using dscreate, then local operations through dsctl and remote or local configuration through dsconf. Replication agreements between suppliers come next, and their topology needs the same care as in OpenLDAP. Access controls (ACIs) decide who reads and writes which attributes, and they can be changed online, which makes them easier to tune later but also easy to loosen by accident. Identity content is loaded with dsidm, and TLS and SASL are configured on the server. Confirm the supplier topology, the ACI model and the TLS certificate chain with your own security team before loading production identities, since those choices are the hardest to reverse. The 389 Directory Server quickstart is the natural starting point for the tooling.

Projects overrun in four predictable places. The first is the replication topology: choosing between OpenLDAP's mirror-style or multi-provider designs, or 389 Directory Server's multi-supplier model, changes failover behavior and is expensive to redesign after applications connect. The second is application LDAP dependencies, since each application's search filters, bind method and attribute expectations often surface only in testing. The third is migration of overlays and identity data. The openldap_to_ds tool covers schema, indexes, backends, data and some overlays, but replication, LDAP proxy, AD synchronization and TOTP are not compatible and need redesign, so inventory those features early. The fourth is failover testing, which should include killing a supplier under load and confirming that clients reconnect. Because these risks are hard to price in advance, ask for a fixed-scope written statement of work that names the topology, the applications in scope, the migration boundaries and the failover tests, with deliverables and timelines agreed before work starts.

OpenLDAP vs 389 Directory Server: questions buyers ask before hiring help

How much ongoing effort does each directory server need to run?

Both are run by a small operations group, but the work differs in shape. OpenLDAP's slapd is configured through its slapd.d LDIF configuration and overlays, so routine work centers on schema, ACLs, replication topology and the MDB database. 389 Directory Server adds a management toolset (dscreate, dsctl, dsconf, dsidm) and a Cockpit console, and its schema, configuration and ACIs can be changed online through LDAP operations without downtime. Effort drivers include how many replication topologies you run, how often you change schema, and whether your staff already know one toolset. Ask your team to inventory these before comparing hours.

Can a small team operate either LDAP server without outside help?

A small team can operate either server if it has at least one person who understands LDAP schema, replication and TLS, and a documented change process. The risk is concentration: one administrator who holds the replication design and the backup routine is a single point of knowledge failure. For OpenLDAP, confirm your team can handle the 2.6 LTS or 2.7 upgrade cycle and the multi-provider replication rules. For 389 Directory Server, confirm your team can work with the dsconf and dsidm workflow and the Cockpit console. Whether you need external operators depends on your staff, not on the product alone.

How long does an OpenLDAP to 389 Directory Server migration take?

The duration depends on the drivers below, and no supplied fact gives a figure, so ask for an estimate tied to a written scope. The main drivers are the amount of custom schema, the number of indexes and backends, how many overlays the directory uses, and whether any OpenLDAP-to-389 replication, LDAP proxy, AD synchronisation or TOTP design must be rebuilt. Each application that binds to the directory adds test effort. Ask for the migration plan, the test cases for each application and the rollback steps as separate line items in any quote.

What does the migration need from our own staff and environment?

Plan for named staff, a test environment that mirrors production, and agreed change windows. Named staff usually include a directory owner who approves schema and ACL changes, application owners who can test binds and searches, and a security reviewer for TLS and certificate settings. The 389 migration how-to notes that the openldap_to_ds tool must run as root or as dirsrv on the 389 host, so your change board needs to approve that access. Ask for the list of required roles, the number of rehearsal runs, and the cutover window in the written scope.

Can openldap_to_ds be used without a consultant?

Yes, the tool is part of the 389 Directory Server code base, so an internal team can run it. It converts an OpenLDAP server on a best-effort basis, covering data from slapcat LDIF exports, index configuration, schema and some overlays. It takes no action unless you pass --confirm, and it only needs to run on the first instance in a 389 topology. Read the migration how-to before running it, because replication, LDAP proxy, AD synchronisation and TOTP are not carried over and need redesign. Many teams use outside help for that redesign and for validating results, which is a scope decision, not a tool limit.

What happens to applications when we cut over to the new directory?

Applications that bind to LDAP can fail if the base DN, schema attributes, password hashes, TLS settings or group membership logic differ after migration. Plan a parallel run where each application is tested against the new server, then cut over in an agreed window with a rollback path. Note that the migration tool does not move replication or proxy designs, so any application that relied on those features needs its own redesign. Ask the provider to list every application connection, its bind method and its test result before cutover.

Do support contracts exist for each server, and where do I confirm them?

Support options exist for both ecosystems, but the supplied facts do not list vendor support terms, so confirm them directly. For OpenLDAP, check the OpenLDAP website for the current 2.6 LTS and 2.7 release status and ask any commercial provider for written terms. For 389 Directory Server, check port389.org and the release notes, and ask whether your Linux distribution's subscription covers the package. DeployOpen supports self-hosted platforms through fixed-scope engagements and retainers, but it does not hold vendor partner status for either project, so confirm scope and service levels in writing.

Can a mixed design with FreeIPA work alongside either server?

Yes, FreeIPA uses 389 Directory Server as its LDAPv3 directory for users, groups, hosts and policies, so a 389-based estate is the natural fit for a FreeIPA deployment. FreeIPA can also set up a cross-forest trust with an Active Directory domain on Windows Server 2008 R2 or later. A mixed design with OpenLDAP is possible, but FreeIPA would then run its own 389 instance alongside your OpenLDAP directory, so you must define which system owns each identity and how attributes sync. Ask for an architecture diagram that shows the source of truth for users, groups and credentials before committing.

How DeployOpen helps choose, implement or migrate an LDAP directory

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so an LDAP directory choice is tested against your real replication, schema and application needs. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we scope

We list the applications, identity sources and clients that will bind to the directory before choosing a server.
The written scope names the replication topology, backend, TLS and SASL requirements and the schema you must keep.
We record which overlays, proxies, AD synchronisation and TOTP dependencies need redesign rather than migration.

How we build

We deploy the chosen server in your cloud accounts, data centers or air-gapped network with documented configuration.
For a migration, we run openldap_to_ds in a test environment first and compare schema, indexes and data against the source.
We test replication, failover, access controls and client bind behavior before any cutover is approved.

How we hand over

You receive configuration, runbooks for dsctl, dsconf or dsidm operations, and a record of every known migration gap.
Backup and restore steps are written down and exercised so your team can run them without us.
Hardening decisions, access controls and evidence for compliance assessments are documented for your auditors to review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover patching of the chosen server line, such as OpenLDAP 2.6 LTS or 389-ds-base releases, within the agreed scope.
Questions about licensing, support windows or edition features are confirmed with the vendor before they reach a decision.

OpenLDAP vs 389 Directory Server