NexTool Solutions

FormCreator was, for years, the most installed GLPI plugin - and in GLPI 11 it stops existing as a plugin. The question is no longer "which one is better" but an operational one: which version are you on, and how do you move the forms already running in production to the new native module without breaking the service catalog.

What changed from GLPI 10 to GLPI 11

On GLPI 9 and 10, custom form is a synonym for FormCreator: a community plugin (maintained by Teclib) that delivers a service catalog, conditional fields, sections and automatic ticket generation from the answers. The last standalone line is 2.13.x - from there on, plugin development stopped.

On GLPI 11, that functionality became a core module: the Forms menu, with a visual editor, sections, conditional questions and destinations (what the form generates - ticket or change). Standalone FormCreator does not run on 11. In its place there is only a transition plugin, the Formcreator Migration Tool (the 3.0.x line), whose only job is to move the old forms into the native module and then declare FormCreator end-of-life (EOL).

Head-to-head comparison

The migration is not a magic button

There is an official migration - and that debunks the myth that "you have to recreate everything by hand". The path is assisted: update FormCreator to 2.13.10 or later while still on GLPI 10, bring up GLPI 11 with the Migration Tool, check the volume under Tools > Formcreator EOL Info and run the migration from the command line.

# 1) Still on GLPI 10: update FormCreator to version 2.13.10 or later.
# 2) Bring up GLPI 11 and install the "Formcreator Migration Tool" (plugin 3.0.x).
# 3) Check the volume to migrate under Tools, item Formcreator EOL Info.
# 4) Run the migration from the CLI, as the web server user
#    (Debian/Ubuntu uses www-data; RHEL/CentOS uses apache):
sudo -u www-data php bin/console migration:formcreator_plugin_to_core

# Correct order when several legacy plugins live in the same environment:
# Generic Objects, then Fields and finally FormCreator.

Before running anything, size the job. A quick inventory in the database tells you how many forms, questions and targets you will have to review afterward - and which ones are the heaviest:

-- Inventory BEFORE migrating: run it on the GLPI database (10, or 11 with the
-- Migration Tool installed) to size the post-migration review.
SELECT
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_forms WHERE is_deleted = 0) AS forms,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_sections)                   AS sections,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_questions)                  AS questions,
  (SELECT COUNT(*) FROM glpi_plugin_formcreator_targettickets)              AS ticket_targets;

-- The forms with the most questions are the ones that need the most review
SELECT f.name AS form, COUNT(q.id) AS questions
FROM glpi_plugin_formcreator_forms f
LEFT JOIN glpi_plugin_formcreator_sections s
  ON s.plugin_formcreator_forms_id = f.id
LEFT JOIN glpi_plugin_formcreator_questions q
  ON q.plugin_formcreator_sections_id = s.id
WHERE f.is_deleted = 0
GROUP BY f.id, f.name
ORDER BY questions DESC;

What the tool migrates well is structure and content: sections, questions and field types. Where it asks for human review is the routing logic - FormCreator used the "target ticket" to set the category, template, group and actors of the generated ticket; on native this becomes destinations, and the import flags the dependencies missing on the target (entity, category) for you to map before finishing.

The trade-off that shows up in support

When you run GLPI estates for clients, the most common mistake is not technical, it is one of expectation: someone runs the migration command, the forms show up in the new menu and the team calls it done. It is not. What migrates is the shell; the core - which ticket is opened, in which category, for which group, with which template - is exactly what needs review. That is why we always migrate into staging first, submit one test ticket per form and compare the routing against the old FormCreator behavior, field by field.

Two details catch first-timers. First: the glpi_plugin_formcreator_* tables stay in the database after migration - nothing is deleted, they become a read/EOL source and do not vanish, so "everything is gone" is usually just the menu that moved. Second: native forms get new IDs (and UUIDs), so any direct link, portal favorite or self-service shortcut that pointed to a FormCreator form stops working and has to be repointed. And there is the silent prerequisite: if FormCreator is on a version earlier than 2.13.10, the Migration Tool simply does not see the forms - updating first is what prevents the "empty" migration.

Verdict by scenario

Stay on FormCreator when the environment is GLPI 9 or 10 and there is no migration to 11 on the near horizon. On those versions it is the mature, no-substitute option for a service catalog and custom forms. Practical tip: keep it on 2.13.10 or later even without migrating now - that is what keeps the migration door open when 11 arrives.

Use native forms when you are on GLPI 11 (or about to migrate). There is no decision to make here: standalone FormCreator does not run on 11, and the native module is the way - no plugin to manage at upgrade, with JSON export/import of forms across environments (something FormCreator never did natively) and dependency reconciliation on the target.

Migrating from 10 to 11, use the official tool but treat it as a project, not a command: inventory the forms, size the review by the number of questions and conditions, migrate into staging, validate each form's routing and only then promote. When several legacy plugins exist, respect the order the documentation itself indicates: Generic Objects, then Fields, then FormCreator.

Cost and effort

License is not the axis of the decision: FormCreator and native forms are free, and on 11 native already ships in the core. The real cost is migration and review. The automatic part - running bin/console - takes from minutes to a few dozen minutes depending on volume. The part that consumes people's time is validating routing and rebuilding the destination logic that did not come over 1:1. As an honest range: for a handful of simple forms, the whole migration fits in an afternoon; for dozens of forms with many conditions, actors and templates, plan for days of review in staging before going live.

At NexTool we deploy and support GLPI for clients across both generations and we run the FormCreator to native forms migration without taking down the service catalog. If you are leaving GLPI 10 and do not want to find out in production what the migration did not bring over, our deployment and migration projects cover that path end to end.

Reviewed by the NexTool Solutions team.