Hello.

The old way: Key Steps to Migrate Lotus Notes Applications 

The AI way you need to be a selected customer: OutSystems Unveils Open Agentic Systems Platform 

 OutSystems also launched Legacy Modernization Services powered by AWS Transform, delivering an automated pipeline that migrates legacy systems based on technologies like COBOL and Lotus Notes into high-performance agentic systems. Kiro development services, as well as Legacy Modernization Services, are available in preview today for select customers with expanded AWS Transform integration capabilities coming in Q3. 

I would explain the situation to your account manager to see if you apply. Otherwise, just wait a few weeks and it will be GA.

Hi Manikandan,

Nuno covered the automated route. If you need to move the data yourself in the meantime, ODC has no Notes-specific importer, but the migration is very manageable if you treat it as three steps: model, extract, load. The modeling step is where most Notes migrations go wrong, so I'd start there.

1. Model: turn documents into entities
Notes databases are document-based and schemaless, so map them deliberately:
- Each Form usually becomes an entity, and its fields become attributes. Check real documents, since old documents often have fields the current form no longer shows.
- Multi-value fields (e.g. several approvers) become a child entity, not a comma-separated Text.
- Response documents (parent/child via $REF) become a reference attribute to the parent entity.
- Readers/Authors fields are row-level security. Recreate them as Roles plus a filter in your server logic, otherwise users will see records they couldn't see before.
- Attachments and rich text: store files as Binary Data in a separate entity linked to the record, and decide early whether rich text is kept as HTML or flattened to text.

2. Extract
- On recent Domino versions, the HCL Domino REST API exposes documents as JSON, which is the cleanest source.
- On older servers, Domino Access Services (/api/data/...) or a small LotusScript/Java agent that writes JSON or CSV per form both work.
- Always export the document UNID (and the parent UNID for responses).

3. Load into ODC
- Small reference data: Excel files and the "Bootstrap from Excel" option.
- Bulk data: expose a REST API in an ODC app (e.g. ImportBatch) that receives batches of a few hundred records into a staging entity, and a Timer that validates and moves them into the final entities. Batching keeps you away from request timeouts.

The tip that saves you later
Add a LegacyUNID attribute (indexed, unique) to every migrated entity and make the load an upsert on it. That makes the migration re-runnable: you can do trial loads, fix mappings and reload without duplicates. Parent/child links can be resolved by UNID after both sides are loaded. At go-live, run a final delta for documents modified after the last full load (Notes keeps a last-modified date per document), so the cutover window stays small.

Before switching off Notes, compare record counts per form and spot-check a sample of documents, including attachments and a few Readers-protected ones.

Hope this helps!