> For the complete documentation index, see [llms.txt](https://docs.migration-center.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.migration-center.com/26.2/sizing-guide.md).

# Sizing Guide

## Introduction

Use this guide to plan the servers and storage for a migration-center installation on either an **Oracle or PostgreSQL** database. Estimate the object count, content size, metadata complexity and number of simultaneous migration jobs.

The hardware configurations below are **initial estimates**, not tested capacity limits.

The [Installation Guide](/26.2/installation-guide.md) and [Database Administrator’s Guide](/26.2/database-administrators-guide.md) contain a full description of the system requirements and installation steps for all migration-center components.\
This document does not substitute them but completes it with information that might be of importance for getting the best migration-center performance.

{% hint style="warning" %}
**Sizing limitation:** Metadata complexity, connector behaviour and simultaneous work can change resource requirements. Test these estimates with typical data and the planned number of simultaneous jobs. Run the full process from scan to import. Measure memory use, database growth, temporary space and processing rates. Repeat the checks as the number of stored objects increases.
{% endhint %}

## Targeted audience

This document is targeted specifically to the technical persons that are responsible with installation and configuration of migration-center components.

## CPU and RAM <a href="#servers-and-component-storage" id="servers-and-component-storage"></a>

Here is a breakdown of the CPU cores and RAM needed, deppending on the size and complexity of the migration project.

Objects values refer to the **maximum number of objects kept the migration-center database**, where each version and update counts as a separate object. Use these bands for initial estimates. \
Select a larger configuration if complex rules or simultaneous jobs need more resources.

The values show **vCPU(cores)** / **total host RAM**.

<table><thead><tr><th width="237" valign="middle">Workload</th><th width="117">Objects</th><th width="103">Database</th><th width="98">WebClient</th><th width="99">JobServer</th><th width="103">Jobservers</th></tr></thead><tbody><tr><td valign="middle"><strong>Small:</strong> few simultaneous jobs, simple attribute mappings</td><td>&#x3C; 5 million</td><td>4 / 16 GB</td><td>2 / 8 GB</td><td>4 / 8 GB</td><td>1</td></tr><tr><td valign="middle"><strong>Typical:</strong> simultaneous scans and imports, transformations with multiple steps or mapping lists</td><td><p>> 5 million </p><p>&#x3C; 50 million</p></td><td>8 / 32 GB</td><td>4 / 8 GB</td><td>4 / 16 GB</td><td>2 - 4</td></tr><tr><td valign="middle"><strong>Demanding:</strong> several active migration sets, many attributes or repeating values, large mapping lists or complex rules</td><td>> 50 million</td><td>16 / 64 GB</td><td>4 / 16 GB</td><td>8 / 32 GB</td><td>4 or more</td></tr></tbody></table>

Select resources for each component based on its workload. More objects increase database storage and can slow queries without enough RAM.&#x20;

Transformations and validation run in the **database**. Scanners and importers content processing run on **Jobservers**. Additional Jobservers help simultaneous scans and imports only if the database, network, source and target systems can process the additional work. \
Large files and connector batch sizes can also increase Jobserver memory requirements.

{% hint style="info" %}
The WebClient and Jobserver each have a default maximum **4 GB Java heap**. Include additional host RAM for the operating system and other process memory. Additional host RAM does not increase the configured heap limit, see the component's administrator's guide for increasing those.
{% endhint %}

#### Single machine install

For a small one machine deployment a **8 vCPU / 32 GB RAM** is a good initial configuration for a shared host.&#x20;

For production, use separate database and Jobserver hosts if their workloads cause resource shortages. Shared content storage gives different Jobservers access to the same exported files. Separate databases can isolate teams or migrations. Object count alone does not determine the number of databases.

## Storage

The storage needed varies for each migration-center component deppending on the specific migration needs.&#x20;

<table><thead><tr><th width="185">Component</th><th>Initial usable disk space, without the operating system</th></tr></thead><tbody><tr><td>WebClient</td><td><strong>5 GB</strong> for application files, temporary files and logs.</td></tr><tr><td>Jobserver</td><td><strong>5 GB</strong> for application files and logs. <br>See specific connector requirements for any needed extra space.</td></tr><tr><td>Database</td><td>See <a href="#database-server">Database Server</a> section below.</td></tr><tr><td>Content staging</td><td>See <a href="#content-staging">Content staging</a> section below.</td></tr></tbody></table>

### Database Server

The migration-center database keeps all source and target metadata, configuration, states, history and reports. **Document content is stored separately.**&#x20;

Count all objects kept together, including selected versions, scanned folders, relationships stored as separate objects, and delta updates. Then use this formula for an initial metadata storage estimate:

```
Storage size estimate = 5 × (NR_OF_OBJECTS) × (AVG_METADATA_SIZE in bytes)
```

Estimate metadata bytes from a sample of typical objects. Include attribute names and all values, including repeating values. Do not include file content.

{% hint style="warning" %}
**Note:** In order to be accessible from any MC client, the scanner/importer report log files are stored in MC database as CLOB fields. If big scanners or importer are run with “debugLevel=4” the size of report logs gets increased significantly and therefore additional tablespace should be taken in consideration.
{% endhint %}

**Example:**

For 800,000 objects with an average source metadata of **5,000 bytes per object**.

<table><thead><tr><th width="334">Storage area</th><th>Example</th></tr></thead><tbody><tr><td>Metadata</td><td>5 × 800,000 × 5,000 bytes = <strong>20 GB</strong></td></tr><tr><td>Additional history and reports, database working space and recovery logs</td><td><strong>15 GB</strong><br><em>(an example estimate to check with the DBA)</em></td></tr><tr><td>Free space</td><td><strong>15 GB</strong><br><em>(or 30% of the total capacity)</em></td></tr><tr><td><strong>Total database storage</strong></td><td><strong>50 GB usable</strong><br><em>(without database software and external backups)</em></td></tr></tbody></table>

The additional 15 GB is an example, not a default for every project. For another workload, add the metadata estimate and additional space. Divide the result by **0.70** to keep 30% free. All examples use decimal GB and TB.

### Content staging

The scanners extract the content from source systems and store it in the specified location.\
The recommendation here is to have a dedicated fileshare to keep all content accessible to all your jobservers under a UNC path.

Start with the actual size of the content to migrate. Include selected versions, renditions and attachments. Document count does not reliably show content size.

* If you keep all exported content until migration acceptance, include space for **all exported content** plus free space.
* If you migrate in groups, include space for the **largest amount kept at the same time**. Include groups that overlap. Use their actual size in bytes.
* If the connector uses existing files or performs an in-place migration, a separate content copy is not always necessary.

**Example:**

For a migration where all exported content takes 2 TB and you need to keep it until finalizing the migration, **provide at least 2.5 TB of usable staging storage.** This gives 0.5 TB of free space for any re-runs of scanners. If the connector creates large additional packages or content copies, include separate space for them.

## Database configuration

For each database there are vendor specific configuration that you should consider to ensure they actually make use of the hardware resources available and perform as expected.

### Oracle <a href="#oracle" id="oracle"></a>

Ask the database administrator to calculate memory and disk requirements for simultaneous operations.

* **Memory:** Include both SGA and PGA in host RAM. Transformations need process memory and cache.
* **Disk:** Include TEMP, UNDO, redo logs, archives and recovery files. Include both `FMEMC_DATA` and `FMEMC_INDEX`, with available disk space for autoextension.

Refer to [Oracle memory management](https://docs.oracle.com/en/database/oracle/oracle-database/21/admin/managing-memory.html) and [performance configuration](https://docs.oracle.com/en/database/oracle/oracle-database/21/tgdba/configuring-database-for-performance.html).

### PostgreSQL <a href="#postgresql" id="postgresql"></a>

Refer to PostgreSQL documentation for [memory](https://www.postgresql.org/docs/18/runtime-config-resource.html), [query planning](https://www.postgresql.org/docs/18/runtime-config-query.html), [WAL](https://www.postgresql.org/docs/18/runtime-config-wal.html) and [autovacuum](https://www.postgresql.org/docs/18/runtime-config-vacuum.html). Use the documentation for your installed version.

Here are example settings for a **dedicated database VM** with **8 vCPU and 32 GB RAM**.

<table><thead><tr><th width="202">Parameter</th><th>How to adjust it</th><th width="85">Example value</th></tr></thead><tbody><tr><td><code>shared_buffers</code></td><td>Start with 25% of VM RAM. Keep memory available for the operating system and other database operations.</td><td><code>8GB</code></td></tr><tr><td><code>effective_cache_size</code></td><td>Estimate the combined database and operating system cache available to queries. This setting does not allocate memory. Reduce it if other memory use leaves less cache available.</td><td><code>24GB</code></td></tr><tr><td><code>work_mem</code></td><td>Memory per sort or hash operation, not per connection. Increase only if temporary disk writes slow queries and enough RAM remains available.</td><td><code>8MB</code></td></tr><tr><td><code>maintenance_work_mem</code></td><td>Memory for operations such as vacuum and index creation. Increase only if maintenance needs more memory.</td><td><code>512MB</code></td></tr><tr><td><code>autovacuum_work_mem</code></td><td>Memory per autovacuum worker. Include all simultaneous workers in the memory estimate.</td><td><code>256MB</code></td></tr><tr><td><code>max_wal_size</code></td><td>Increase if the server log reports frequent checkpoints caused by WAL growth. Allow additional disk space. This is not a hard disk limit.</td><td><code>4GB</code></td></tr></tbody></table>

Several query operations, sessions and parallel workers can each use `work_mem`. Hash operations can use more through `hash_mem_multiplier`. Do not calculate `work_mem` from RAM divided by `max_connections` alone. Larger `max_wal_size` values can also increase crash recovery time.

Include disk space for temporary files, maintenance, WAL and archives. Frequent updates need space for obsolete row versions until vacuum makes that space available again.

Keep autovacuum enabled. Check that it removes obsolete row versions and updates table statistics during migration. If it cannot keep up, ask the database administrator to adjust thresholds or worker capacity for the affected tables.

Set `max_connections` to cover WebClient and Jobserver connection pools, plus administration access. Additional connections or parallel workers do not automatically improve performance. Start with the default parallel worker settings and adjust them only after a test shows a benefit.

Apply settings in `postgresql.conf` or the managed service configuration. A change to `shared_buffers` requires a PostgreSQL restart. Reload the configuration for other settings in this table. Use `SHOW` to confirm effective values, for example, `SHOW work_mem;`.

Test simultaneous scans, transformations and imports. Check available RAM, swapping, temporary disk writes, checkpoint frequency and processing rates. Change one setting at a time and repeat the test. Avoid memory increases if the VM already swaps or has memory errors.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.migration-center.com/26.2/sizing-guide.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.