Why migrate Formcreator forms to GLPI native forms during the GLPI 11 move
If your GLPI 10 or earlier instance has self-service forms built with the Formcreator plugin, those forms need a planned path into GLPI 11, where forms now live in the core. The supported route is the Formcreator Migration Tool, version 3.0.0, which prepares Formcreator data for migration to native forms. You install it only for the duration of the migration, then run php bin/console migration:formcreator_plugin_to_core from the GLPI folder with the Formcreator plugin installed, as the GLPI forms documentation describes. Confirm the exact command output and any prompts against the version you run, because the migration is a one-time operation on your data.
The form migration is not a standalone task. It sits inside the wider GLPI 10 to 11 upgrade, which also involves PHP and database prerequisites, plugin reactivation after a major update and the other plugin data migrations. Sequence the forms work after you have a tested copy of the GLPI 10 database and a GLPI 11 target that runs your required PHP and database versions, so that a failed form import does not block the rest of the upgrade. Ask whoever runs your upgrade to confirm which plugin versions are compatible with the target before you start.
Native forms can create tickets, changes or problems, can create several items from one form, and can be public or restricted to users, groups or profiles. That broader model is why the migration needs review rather than a simple import: each Formcreator form's destination and access settings must map onto a native equivalent, and you should confirm that every question type and target survives the move. Plan time to test each migrated form as an end user would, and keep the Formcreator data until that testing is signed off.
What changes for forms, tickets and users in GLPI 11
This table compares how Formcreator forms behave today with how they behave as GLPI 11 native forms, row by row. Read each row as a question to answer before cutover: what the form creates, who can submit it, and which plugin steps must happen first. The main takeaway is that the migration changes the item types and access model of each form, so every form needs a check after it is moved, not just a successful run of the migration command.
| Change | Impact on forms, tickets and users | Action needed |
|---|---|---|
| Forms move from the plugin into the GLPI core | Formcreator forms are converted into native forms with the core migration command, not reused as plugin objects | Install the Formcreator migration tool version for the run, then confirm each form exists as a native form |
| Native forms create tickets, changes or problems | A form that opened tickets may now need a different target type, so requesters may see a different item type | Check the target type for every form and confirm downstream rules, SLAs and approvals still apply |
| One form can create several items | A single submission may now generate multiple tickets or linked items, changing counts in reports and queues | Review forms that created more than one item and test notifications and assignment rules |
| Public access via unauthenticated link | Forms shared by link can accept submissions without a GLPI login, so anonymous requests reach your queues | Confirm which forms should stay public and review their rights and anti-spam controls before go-live |
| Access limited to users, groups or profiles | Restricted forms depend on the access model in the new instance, so requesters outside the listed groups lose access | Map each Formcreator target audience to users, groups or profiles and test with a requester from each group |
| Plugins suspended after a new version is detected | GLPI 11 suspends plugins after a new version is detected and they must be reactivated after major updates, so Formcreator may stop accepting submissions until handled | Plan Formcreator reactivation or retirement as a named step in the upgrade runbook, and test on a copy first |
What to prepare before running the Formcreator migration
The migration changes live self-service forms, so the work before the console command decides how safe it is to run. The cards below cover the recovery points, the rehearsal copy, the test environment and the inventory of who depends on each form.
Full backup of the instance
Take a backup of the database, the GLPI files and the config directory before anything changes. The config directory holds glpi.key and glpicrypt.key, and without them encrypted values in the restored database cannot be read. Confirm with your own backup tooling that a restore has been tested, not only that the archive was created. Keep the backup until the migrated forms have been checked in production.
Copy of production for rehearsal
Restore a recent copy of the production database into a separate environment and run the migration there first. Compare the forms, targets and visible questions before and after, using the same user accounts that raise tickets today. The rehearsal shows what a live run would change, so the production window can be planned against known results. Record how long the rehearsal took so the cutover plan reflects real data volumes.
Test environment matching GLPI 11.0 prerequisites
Prepare the test environment with PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6, the prerequisites the GLPI installation docs list for GLPI 11.0. Confirm which GLPI version your target instance will run, because later releases may have different requirements. Check the prerequisites page against the version you plan to deploy before you build the environment, and match the web server layout to production.
Inventory of every Formcreator form
List each Formcreator form with its owner, its current request target (ticket, change or problem), and the groups that submit it. Note any form that creates several items, because those need checking after the move. Mark forms that are no longer used so they can be retired instead of migrated. An inventory with named owners gives the reviewers someone to confirm each migrated form against.
Access settings for each form
Record which users, groups and profiles can see or submit each form, and which forms are open to unauthenticated users through a link. Native forms can be public or restricted to users, groups or profiles, so the mapping must be confirmed for each form after migration. Note any form that depends on a group that will change in your directory. These settings are the first thing users notice when they fail to see a form.
How the Formcreator to native forms sequence runs
The sequence moves Formcreator forms into GLPI 11 native forms on a tested copy first, with a check and a rollback point at every stage, so the production instance changes only after the migrated forms have been verified. It also keeps the migration tool installed only for as long as the migration needs it.
Back up the production instance
Before any change, take a database dump, a copy of the GLPI files and the config directory, including glpi.key and glpicrypt.key, following the backup requirements in the GLPI update procedure. Store the backup somewhere you can restore from without touching the live instance. The step is complete when you have tested a restore of the database dump to a scratch host and confirmed the forms and their targets are present in it. That restored copy is your first rollback point.
Build a test copy of the GLPI 10 instance
Restore the backup to a separate environment that mirrors production's web server, PHP, database and plugin versions. Keep it isolated from production mail, LDAP and external notifications so test runs do not send messages or sync accounts. The step is complete when the copy loads, a sample of Formcreator forms opens in the plugin interface, and the form count matches production. Record the counts so you can compare them after migration.
Install the Formcreator Migration Tool on the GLPI 11 target
On the test GLPI 11 target, install Formcreator version 3.0.0, the Formcreator Migration Tool, alongside the existing plugin files. Activate it as the update procedure requires, since GLPI 11 suspends plugins after a new version is detected and they must be reactivated after a major update. Confirm the plugin reports version 3.0.0 and that its forms are readable. The step is complete when the migration tool is active and the test target still loads without errors.
Run the core migration command
From the GLPI folder, run php bin/console migration:formcreator_plugin_to_core on the test target. Read the console output for each form it converts and for any it skips or reports. Keep the full output in your change record, since it is the list you will check against. The step is complete when the command finishes without a fatal error and every skipped or warned item has a documented reason. If it fails, restore the test copy from the step one backup and correct the cause before retrying.
Verify migrated forms in the core
Open each migrated form as a native form and check its question types, the targets it creates (tickets, changes or problems), the Fields dependencies between questions, and the access settings, whether public or restricted to users, groups or profiles. Submit one test request per form type and confirm the item created matches the expected target and fields. Compare the migrated count with the count recorded in step two. The step is complete when every form passes these checks or has an agreed fix recorded.
Repeat the migration on production
Once the test migration passes, schedule the production change, take a fresh backup, and replace the application files with the GLPI 11 release as the update procedure describes. Then run php bin/console db:update, activate the migration tool, and run the migration command again. Repeat the form checks from step five on production with a small set of test submissions. The step is complete when production forms match the verified test results. If they do not, restore from the fresh backup before the forms are opened to users.
Remove the migration tool and retire the plugin
After production verification, deactivate and uninstall the Formcreator Migration Tool, since the plugin documentation says it should be installed only for the duration of the migration. Confirm the native forms still load and submit correctly with the tool removed, and keep the pre-removal backup for a period your change policy sets. The step is complete when the tool is absent, the forms still work, and the change record shows the final form counts and the backup retained.
When to retire the Formcreator plugin and what to remove
The Formcreator Migration Tool, version 3.0.0 of the Formcreator plugin, should stay installed only for the duration of the migration. Once your forms are verified in GLPI 11 native forms, remove the migration tool and retire the plugin rather than leaving it active alongside the core forms. The GLPI Formcreator documentation describes the tool as preparing Formcreator data for migration, so its job ends when the data has been moved. Keeping it enabled after that point adds a second form engine to maintain through future upgrades without giving you anything the core needs.
Before removal, confirm three things in writing. First, every migrated form has been checked against its source, including question types, targets and the Fields dependencies that drive conditional display. Second, keep rollback copies of the pre-migration database and the Formcreator plugin files for as long as your own retention policy requires, since removing the plugin does not remove its data and a restore may be needed if a defect surfaces later. Third, confirm that no integration, script, webhook, bookmark or external portal still calls Formcreator endpoints or expects its URLs. Search your monitoring, reverse proxy logs and automation configuration for the old form paths, and point each one at the native form before you retire anything.
Plan the removal as its own change with a named owner, a test run on a copy of the GLPI 11 instance, and a rollback step agreed in advance. Ask your DeployOpen contact, or your internal team, to document exactly which plugin files, configuration and database tables are affected by disabling and removing Formcreator, and to confirm that the native forms keep working afterward. Confirm the exact removal steps against the plugin documentation for your installed version, since this section deliberately does not list commands beyond what the supplied facts support.
Which checks apply to public, restricted and multi-item forms
Public native forms can be submitted by unauthenticated users who open a link, so they are the highest exposure after migration. Formcreator forms that were reachable without a login need the same question, target and access checks as any other form, plus a review of what an anonymous submitter can see or trigger. The migrated form should be tested from a clean browser session with no GLPI login, because a session left open in your own browser can hide access problems.
- Access setting: Confirm the form is still public after migration and that it is not accidentally restricted to a profile or group, which would block the intended users.
- Question types: Submit each question type, including file uploads and any fields that were hidden or required in Formcreator, and confirm the values reach the ticket.
- Fields dependencies: Trigger every conditional path from an anonymous session and confirm that a hidden field does not still send data.
- Target defaults: Check the ticket category, urgency, entity and requester that the target assigns to anonymous submissions.
- Information shown: Review what the confirmation page and notifications reveal about existing tickets or internal users.
Confirm each of these checks in your migrated instance, using your own test accounts and the form configuration you approved for production.
Restricted native forms are limited to specific users, groups or profiles. Migration can change who sees a form if the Formcreator access rules do not map cleanly to the native visibility settings, so each restriction needs a positive and a negative test. A form that is visible to too many people is a data exposure issue, and a form that is hidden from its intended group is a service issue.
- Visibility mapping: Compare the users, groups and profiles allowed in Formcreator with the native access settings and record every difference.
- Positive tests: Sign in as one member of each allowed group or profile and confirm the form appears and submits successfully.
- Negative tests: Sign in as users outside each allowed group or profile and confirm the form is not listed and cannot be opened by direct link.
- Entity scope: Check that requesters in different entities see only the forms and created tickets that their entity should see.
- Question types: Confirm that dropdowns and fields that load values from users, groups or assets still show only the values the requester is allowed to see.
Confirm these mappings with your own role model, because group membership and profile names in your directory are your decisions, not defaults that the migration can infer.
Native forms can create tickets, changes or problems, and one form can create several items from a single submission. Formcreator forms that created one ticket may have been reshaped during migration, so the number and type of items created must be counted again. An unexpected item count or item type can route work to the wrong queue and distort reporting.
- Item types: Submit the form and confirm whether each target creates a ticket, change or problem, and that the type matches what the original form created.
- Item count: Count the items created per submission and compare the result with the original Formcreator behavior for the same answers.
- Dependencies between targets: If one target depends on values from another, test the path where a conditional target is skipped and the path where it is created.
- Requester and assignee: Check that each created item gets the correct requester, category and assignment, and that notifications fire once per item rather than once per form.
- Duplicates: Submit the same form twice and confirm that the second submission does not reuse or duplicate items unexpectedly.
Confirm the item counts and types in your migrated instance with test submissions that cover each conditional path, because the number of items a form creates depends on your target configuration.
Some checks apply to every migrated form regardless of access model. These include the question types that carry the most migration risk and the Fields dependencies that control what appears on the form. Running the same test script against all three situations avoids gaps, because a public form can share a question with a restricted form and the same mapping error can appear in both.
- Question types: Inventory every question type used by each form and test each one at least once in the migrated instance.
- Fields dependencies: Map each dependency rule from Formcreator to the native equivalent, then test the value that shows the field and the value that hides it.
- Targets: List every target, its item type and its default values, and compare them with the approved design.
- Access settings: Record the public or restricted setting for each form and the owner who approved it.
- Retirement: Keep a dated test record so you can show the state of each form before the Formcreator plugin is removed.
The test scripts and approvals are yours to define and keep, and they should be reviewed against your own change process before any form goes live.
What makes the Formcreator migration take longer
This table lists the factors that stretch a Formcreator to native forms migration and what each one does to the work. Read each row as a question to answer during scoping, because the mitigation usually costs less when it is decided before the build starts. The main takeaway is that dependencies between forms, targets and downstream consumers, not the form count alone, set most of the effort.
| Effort driver | Why it adds effort | How to keep it down |
|---|---|---|
| Number of forms and Fields dependencies | Forms that show or hide questions based on other answers must be checked as a set, and one broken dependency can affect several forms. | Inventory each form and map its Fields dependencies before the migration tool runs, then migrate and test the most connected forms first. |
| Question types in use | Each type must be checked against its native equivalent, and types without a clean match need a redesign of the question or the form. | List every question type in use across all forms and confirm the native equivalent for each before the test copy is built. |
| Custom plugins or integrations reading form targets | Anything that reads ticket, change or problem data created by a form may depend on fields or targets that native forms handle differently. | Identify every consumer of form-created items, including custom plugins, reports and webhooks, and test each one against items created by native forms. |
| Volume of submitted data | Large numbers of past submissions take longer to check and can make the test copy slower to build and reload. | Decide which historical submissions must come across and which can stay in an archive, and size the test copy to match. |
| Access groups and profiles per form | Forms restricted to users, groups or profiles need their rights rechecked after the move, and a wrong right can hide a form from the people who use it. | Export the current visibility settings for each form, then confirm the same users, groups and profiles can see the native version. |
| Number of test cycles | Each defect found in testing sends the form back through migration and checks, so the count of cycles drives the schedule more than any single step. | Agree on acceptance criteria and a fixed number of test rounds in the written scope, and ask the partner how they track defects between rounds. |
Questions buyers ask before moving Formcreator forms to native forms
What drives the cost of moving Formcreator forms to native forms, and who pays for what?
Cost follows the number of forms, how many question types and targets each form uses, and how many forms depend on custom logic or integrations. A partner is typically paid for the inventory, the test migration on a copy, the rebuild or correction of forms that do not map cleanly, the testing with your owners, and the cutover. Your team pays internally for the time its form owners and approvers spend reviewing results. The work is usually a one-time project, while GLPI itself carries its own recurring licensing or hosting costs only if you choose a subscription. Ask any quote to list each phase, the form count it assumes, and which items are excluded, such as new form design.
How long does a Formcreator to native forms migration take?
Duration depends mainly on how many forms exist, how complex they are, and how quickly your owners can review them. The migration tool itself runs as a console command, so the technical run is rarely the long part. Most of the time goes to checking each form's question types, its targets (tickets, changes or problems), and any Fields dependencies, then fixing what did not carry over. Plan extra time if forms are public, because you must confirm which links remain reachable and who can see them. Ask for a timeline that separates inventory, test migration, review and cutover so each phase can be tracked against the plan.
What do we need to provide before the migration starts?
You need a current inventory of every Formcreator form, including its owner, its targets, whether it is public or restricted to users, groups or profiles, and which other GLPI features it touches. You also need access to a copy of your GLPI database and files, with a GLPI 11 instance and the Formcreator plugin version that serves as the migration tool available for the test run. Name a sign-off owner for each form family and one person who approves cutover. Without those inputs, review cycles stretch because questions go back and forth. Confirm the exact versions and access steps with your GLPI administrator before scheduling work.
Can our own team run the Formcreator migration without a partner?
Yes, a capable GLPI administrator can run the console command on a test copy and review the results. The harder part is judgment: deciding whether a form that changed shape still behaves the same for requesters, and whether its tickets, changes or problems route correctly. Teams that do this in-house usually need time from people who know the forms and the approval chain, not only from the administrator. A partner can take on the inventory, test runs, correction work and documentation. Whichever route you choose, ask the decision-maker to agree the acceptance criteria in writing before the production run.
What breaks if we do not check forms after migration?
Forms can appear to migrate successfully and still create the wrong item type, send requests to the wrong target, or lose a dependency that controlled which questions appear. Public form links may stop working or expose a form to the wrong audience if access settings were not reviewed. Requesters may see empty or renamed fields, which leads to incomplete tickets and slower service. Checking each form end to end, from submission to the created item and its assignment, is the only reliable way to catch these faults. Keep the list of checks with the change record so an auditor or service owner can see what was verified.
What happens to recurring costs after the Formcreator plugin is retired?
Retiring the plugin removes its maintenance work, since you no longer need to track its compatibility with each GLPI major update. The plugin is meant to be installed only for the migration, so most of its ongoing effort ends at cutover. Recurring costs then shift to native forms, which are part of GLPI core, and to the normal platform upkeep you already fund, such as backups, patching and upgrades. Confirm with your administrator that no other plugin depends on Formcreator tables before removal. Ask any quote to state which recurring items remain after cutover and which ones end.
Which Formcreator features are most likely to need rework?
Forms that rely on complex dependencies between questions, custom validation, or targets that depend on answers are the most likely to need manual correction. Public forms and forms restricted by group or profile also need access rechecks, because permissions may not map exactly as they did before. Forms that feed external integrations or notifications should be tested end to end, since their downstream behavior depends on the exact item created. Build a short list of these high-risk forms during inventory so reviewers and the engineer can give them the most attention.
How DeployOpen works on this
DeployOpen plans and delivers GLPI form migrations inside infrastructure you control, starting from a written scope that names every form to move. The work runs on a copy of your GLPI 11 instance first, so your team can check each migrated form before anything changes in production.
How we scope
- Inventory every Formcreator form, its targets, question types and Fields dependencies before any migration starts.
- Record which forms are public, which are restricted to users, groups or profiles, and who owns each one.
- Agree the scope in writing, since most engagements are fixed-scope with deliverables and timelines set in advance.
How we build
- Run the migration tool version of Formcreator on a copy of the GLPI 11 database, not on production.
- Run migration:formcreator_plugin_to_core from the GLPI folder, then review each converted form against its original.
- Test ticket, change and problem creation, plus restricted access and public links, using test accounts for each profile.
How we hand over
- Deliver a register of migrated forms showing source, target item type, owner and access settings.
- Document the checks performed, any forms rebuilt by hand, and the steps used to remove the plugin afterward.
- Walk your administrators through the native forms configuration so they can maintain forms after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the work that follows the migration.
- Confirm with your team how plugin reactivation and later GLPI updates will be tested on your own environment.
- Keep backups of the database, files and config directory, including glpi.key and glpicrypt.key, before each change.
