Prerequisites

• Lialis Notes2SQL requires a IBM HCL Domino server version 9 (or higher).
• The Domino server must run on a Windows 2012 server (or higher).
• For configuration of the Notes2SQL tool you need a Notes client version 9 (or higher).
• SQL server, for example Microsoft SQL Express or SQL Server Developer.
• Microsoft Excel does not have to be installed on the migration server in the case of Notes database exports to Excel.

High-Level Migration Setup

Notes2SQL must run on a HCL Domino server; it is NOT a migration tool that executes in a (Notes) client program. We recommend setting up a dedicated Domino server (see prerequisites) to run the Lialis Notes2SQL software, which operates as a Notes application.

Replicate the Notes databases from the production server to this dedicated migration server using push-only replication. Grant the Domino server running the Lialis tooling Reader access to all databases, including all ACL roles.

Its possible to allow the Domino server running Notes 2 SQL tool to access Notes databases on other Domino servers, but then the Notes 2 SQL Domino server must be trusted in the source Domino server document.

This setup ensures that the migration process does not affect the production environment.
Schedule regular replication — for example, once per week — from the production server to the migration server. This allows Notes2SQL update runs to execute smoothly and keep the SQL databases up to date.

Preparations

Make sure your Notes client has this Notes.ini setting: JavaMaxHeapSize=512mb, this is needed to carry out the license validation.

Make sure the Domino server has below Notes.ini settings present:

HTTPJVMMAXHEAPSIZE=256M
HTTPJVMMAXHEAPSIZESET=1

Store a copy of the Notes2SQL software (LNXtract.nsf) on the Domino server (R85 or higher). The file name and Notes db title is not relevant.

Subsequently, sign it with the Domino server ID and set the ACL properly (Domino server and Domino admin must have manager access with delete and the role Admin attached).

The Notes2SQL conversion agent needs at least “Sign or run restricted LotusScript/Java agents” access on the Domino server. Therefore the Notes2SQL NSF must be signed with a Notes ID that has this access.

The agent may run for a long time depending on the size of the database that you convert. We advise to have the “Max LotusScript/Java execution time” set at at least 6 hours.

The runtime (180 minutes)  is used in the estimation of how many documents to select each run. With a large runtime, the chance to overestimate gets larger too.
Since searched documents in Notes are in no particular order, it is unknown which documents of the selection have been done, and which haven’t been done.
This means the next run will have to do the same documents again, with a smaller selection of documents. Increasing the total runtime.

In some cases, migration runs can take days or even weeks. The Lialis Notes 2 SQL tooling monitors the maximum agent runtime on the Domino server and will automatically stop just before the server terminates the agent. On the next run, it will continue using the updated agent runtime settings. This ensures you don’t have to worry about the Domino agent timeout being shorter than the total migration duration.

Configuration of the Notes2SQL software

Choose Add license to add the Lialis license key we will provide you after you have purchased the software.

Leave it empty if you only want to evaluate the software. Please note that an conversion limit is applicable in this evaluation version.

Then click the big red button to start the IBM Domino conversion background agent for the conversion of the Notes content to SQL. After clicking, the button will turn to green.

The agents are now signed with your Notes ID, so its advisable to sign the Lialis Notes to SQL db again with the Domino server ID. In Domino admin client right click on the Notes app and choose sign, then choose active server ID. Then AdminP will do the signing and if you are in a hurry you can issue Domino command tell adminp process all.

Subsequently, select General Settings to configure the SQL server connections. Notes2SQL only supports Microsoft SQL server over OLEDB protocol.

To connect to the SQL server it requires the connection IP address or DNS name to the SQL server and login credentials of a user with SQL database administration privileges.

The test Export folder is for conversions of Notes databases to Excel and to export the fields the Notes database has to Excel .

Always enable the Experimental option, this option will be removed from the settings in the version 2.18 as it becomes standard.

Notes database migration to SQL

Please click Add Notes Application to choose the Notes NSF file you wish to convert to SQL.

Then select the Notes database and press Start Application Analysis. The Domino server will automatically take care of the Notes to SQL migration duties.

Analyze the Notes data

In this phase, the software checks every field on every document in the Notes database to determine its details — such as type, content, length, whether it’s multi value, rich text, etc. This information is required for the next step, where the SQL tables will be created. When this phase is completed, you will find details like the example below in the Notes database record. We dont look at the Notes forms to determine the data that is stored in the Notes documents.

Each form in the Notes database is listed under Forms, where you’ll find detailed information about all fields found across all documents.

You complete the preparations when the status changes to “Fields mapped“. This basically means that the Notes2SQL field mappings for all forms in the Notes database are in place.

Please open the Notes db record for details on the forms and fields analyse results.

A field mapping example is displayed in the image below.

Analyse and mapping logs

Are displayed at the bottom of the Notes database record in Lialis

Explanation of Source fields scan

Before any Notes document is migrated, the tool first scans all fields in all documents in the entire Notes database. Notes is schema-less: every document can have different fields, different datatypes, different multi-value structures, and even rich-text or attachments. To migrate this safely into SQL, the tool needs to figure out exactly which SQL tables and columns are required. So the tool runs a full field analysis and produces a mapping table like the one above. Every row describes one Notes item (field) and how it should look in SQL. A few examples of this scan are listed below:

WRMCancellationDate;wrmcancellationdate;26328;nvarchar(max);1;10;DATETIMES(11989)|TEXT(14339);true;STRING|-
WRLASTSTATUS;wrlaststatus;93958;nvarchar(15);1;3;TEXT(93958);true;STRING|-
ComposedDate;composeddate;100022;datetime2;1;10;DATETIMES(100022);true;STRING|-

Explanation of the first example:

WRMCancellationDate : The original Notes field name found in the documents.

wrmcancellationdate : The name of the SQL column the tool will create. If this is “-”, the Notes field is not migrated to SQL because the field is always empty across all Notes documents.

26328 : How many documents contain this field. This is important because Notes allows fields to exist in some documents but not others.

nvarchar(max) : The chosen SQL data type that best matches the Notes datatype.

1 : Max elements found for this field (Notes multi value field)

10 : Max field length in bytes

DATETIMES(11989)|TEXT(14339) : for the field 11989 Notes documents have a date time value in it, 14339 Notes documents have a text value in this field. Its advisable to be aware of these type of fields as they can make the content migration more complex.

true : When this field has different values across all documents the value is true, if this field has always the same value its false, when this field is not present on a document its ignored, empty strings are not ignored

STRING| – : Explicitly defines the datatype of the value that follows. This is used to enable type-safe comparisons between documents (for example text versus date or number), with | acting as a fixed separator between datatype and value.

Above information is crucial and will be used by the tooling to create the SQL tables schema later on.

High number of fields on documents

A SQL database has limits on the number of columns and on the size that can be assigned to those columns; these limits are determined by the specific database system.

• Max columns per table: 1,024,
• Max row size: 8,060 bytes,
• Max columns that count toward row size: depends on data types
• varchar / nvarchar / varbinary (MAX):
  • Up to 2 GB per column
  • Stored off-row, so they don’t fully count toward the 8,060 bytes
• Non-MAX variable columns (varchar, nvarchar):
  • Still limited by the 8,060-byte row size

Practical takeaway:

• You can hit the row-size limit long before 1,024 columns
• Many wide Notes-to-SQL migrations break on row size, not column count

Lialis has a built-in function to help you identify whether you might run into the above issues: simply press the Actions → Split Tables button.

The result of Split Tables is displayed below, 2 new Notes db records where added to the Lialis tooling (items 2 and 3 in the list).

The plan is to convert this Notes database into two SQL tables due to the large number of fields on some documents: SQL DB 00 and SQL DB 01 (the second and third items in the list). The Lialis tool sorted the fields alphabetically and performed a safe split, dividing the fields into two batches.

So in SQL DB 01 you will only find the forms where the number of fields was too large. For forms with a normal number of fields, all data is stored in SQL DB 00. For forms with too many fields, the data is split across both SQL DB 00 and SQL DB 01.

In this example, only records marked SQL DB 00 and SQL DB 01 will then continue to the next step, SQL initialization. The first item remains in the status Fields Mapped.

We have encountered Notes databases where we needed 10 SQL databases because the number of fields exceeded 1,500 fields.

SQL Initialisation

Next in line is to click Start SQL Initialisation to create an empty SQL database with all the required tables and columns.

After a few minutes an empty SQL database has been created by the Domino server as you can see below.

SQL Data Migration

Finally, click Start conversion (Once) to send the Notes content to the SQL database. The Domino server will execute this action.

Conversion Modes

Lialis Notes2SQL offers two ways to perform the content conversion:

Start Conversion Once – Executes a single full conversion run.
Use this option when you want to migrate the Notes database content to SQL only once.

Start Conversion – Performs a complete initial conversion and automatically continues with regular update runs.
This mode keeps the SQL database synchronized with the Notes database by processing newly added, modified, and deleted documents.

Actions menu explained

Admin \ Reset Running Flag – this icon displayed in the image below is the running flag. When you encounter a Domino server crash the tool still thinks its busy migrating this particular Notes db, so it will skip it, only in this case you will have to use this option to remove the running flag.

Admin \ Reset Conversion – when you use this option on a Notes application in the tool it will reset the conversion. In the next run the migration will start from scratch.

Disable unchanged fields – This operation removes Notes fields from the migration that are always empty or always contain the same value. This can drastically clean up the Notes fields migrated to SQL. Disclaimer: In version 2.19 this analysis removes too many fields. If you need this function, please let us know.

The fields selected by this operation are placed under Design Disabled Fields (scroll down).

Export fields to Excel – you can export the fields to excel to investigate the Notes content, for example

You are free to remove Notes fields you don’t want in SQL, rename SQL columns settings, and later import your modified migration setup back into the Lialis tooling for migration to SQL. Keep in mind that this work is complex and requires a good understanding of the setup—otherwise issues may occur.

Generate Report – Instructs the tooling to generate a report, only possible when the migration method in migrate once.

Import fields to Excel – Import your altered Notes field-to-SQL column XLS mapping into Lialis Notes to SQL.

Open Application – opens the Notes application.

Split Tables – already explained earlier in this guide.

Reporting

When the migration to SQL is complete (only for option Conversion Once), the software automatically generates a migration report comparing the number of Notes documents per form with the corresponding SQL tables to identify mismatches.

If fewer documents appear in SQL, you can use the built-in function that identifies which Notes documents (by Notes Document ID) did not make it into SQL, allowing you to investigate further.

The conversion reports are stored here in the Lialis Notes 2 SQL software:

Processing of Notes document updates to SQL

Lialis Notes 2 SQL is capable of migrating updates to SQL, as the Domino server Agent Manager runs the SQL migration tasks every few hours. Make sure the conversion mode is set to Conversion and not Conversion Once.

A typical migration log is displayed below: green shows the initial migration, and red shows the update runs.

2025/12/30 16:42:03 Conversion start
2025/12/30 16:42:03 Processing database: Dossiers Lialis
2025/12/30 16:42:04 Selected 181 documents modified between 12/30/2025 14:56:44 and 12/30/2025 16:42:03
2025/12/30 16:44:46 181 documents processed; 181 documents updated
2025/12/30 16:44:46 Start processing of deletion stubs
2025/12/30 16:44:46 0 deletion stubs processed
2025/12/30 16:44:46 0 records deleted
2025/12/30 16:44:46 Database converted
2025/12/30 16:44:46 Conversion done
2025/12/30 17:04:01 Conversion start
2025/12/30 17:04:01 Processing database: Dossiers Lialis
2025/12/30 17:04:01 Selected 1 documents modified between 12/30/2025 15:25:56 and 12/30/2025 17:04:01
2025/12/30 17:04:05 182 documents processed; 1 documents updated
2025/12/30 17:04:05 Start processing of deletion stubs
2025/12/30 17:04:05 0 deletion stubs processed
2025/12/30 17:04:05 0 records deleted
2025/12/30 17:04:05 Database converted
2025/12/30 17:04:05 Conversion paused, will continue later 

Our tooling always adds the Notes created and modified date/time to the SQL tables, next to the document ID column. This helps you verify whether updated records from Notes are correctly stored in the SQL database.

When a Notes document is updated the tool will overwrite the record in SQL.

When a Notes document is deleted the tool will remove the record ion SQL.

A handy approach is to add an **All-by-Form** view to the Notes database; this also shows the modified dates.

Missing records in SQL compared whit Notes database

In some migration projects we see differences between the number of Notes documents for a certain form and the number of items in SQL. When a Notes database contains many thousands of documents, it’s very hard to determine which ones are missing. Once you know which items are missing, you can investigate the cause.

Use the option Find Missing Records. The Domino server will perform this check, and the results are stored in the Missing Records Reports. Keep in mind that this operation can take some time. To use the Find Missing Records option you must first stop the conversion by the way.

After some time the report will be stored here:

Parallel processing

You can use parallel processing very easily. Simply make copies of LNExtract.nsf and give them numbers in the file name and title, for example: LNExtract 1, LNExtract 2, etc. Then you can load different Notes databases into each LNExtract and let the Domino server run the migration agents in parallel. Of course, make sure the server has enough CPU and RAM to handle the load.

Excel

The software can also export to Excel very well, but you may run into Excel limitations when the number of columns (i.e., Notes fields) becomes very large. We’ve seen this in several projects where the field count exceeded 1,000 columns.

Notes profile documents

Notes profile documents are not exported to SQL, instead the tool has a menu action that will take all profile documents and exports them in text format on your PC.

The result is displayed below

Notes code base

To be clear: the content is migrated to SQL exactly as it exists in the Notes database. Notes application logic is not exported.
This means SQL will not contain: form design details, field formulas or computed logic, subform structures, agent logic or run details, UI-level relationships between documents. For insight into the Notes design and code structure, please refer to our Notes code base AI tooling.

Exporting SQL MIME data

Notes rich text field data is stored in Mime format in SQL columns. The image below displays a SQL column holding Notes rich text data.

Keep in mind that the copy operation in SQL Server Management Studio will only copy 64K of data,  so you dont get the full information this way.

Follow below steps to extract all MIME data from SQL and extract the text, attachments images and so on.

Download Mimekit from here : https://www.myget.org/feed/mimekit/package/nuget/MimeKit

Rename the MimeKit.4.14.0.1838.nupkg file to *.zip so you can unzip the package and store the folder on the migration server, for example:

Install Thunderbird browser as its very good to view the eml files we extract from the SQL.

Install Power-shell version 7.5.*

Install Visual Studio code as its great in Power shell running scripts

The code

The result of this script will look like this:

Challenges

The software has been successfully executed on very large Notes databases — for example, NSF files of around 100 GB, databases with millions of documents, and Notes form designs containing up to 1,500 fields. The tooling is therefore well-hardened.
However, every new project brings new challenges, because each Notes environment has its own unique complexities when migrating to SQL.