Blog

An IFS Cloud project needs as many environments as it has purposes that cannot share a system without damaging each other. IFS does not set a norm for this, and I would distrust any answer that gives a single number without asking about the project. A small single-site rollout can run on a configuration environment, one test environment and production. A multi-site rollout with integrations, a data migration and a formal acceptance cycle usually needs more, because the people testing cannot work on a system that the configuration team changes every day.

The table below is the layout I start from in projects, then reduce or extend.

One system can serve two purposes when the schedule allows it, for instance training on the same environment that later becomes the rehearsal system. The rule is that two purposes never run at the same moment on the same system. The Test Strategy template (IDK-17) is where the layout and the rule for each environment get written down, and the Cutover Plan template (IDK-20) is where the rehearsal environment is named.

According to IFS Community users, Build Place is where the IFS Cloud environments of a customer exist, and Use Place is the place where the system runs for its users. I could not find a page in the IFS documentation that defines either term, so this section rests on a community thread and not on documentation: IFS Build Place environments (thread 60929).

According to that thread, Build Place offers environments of three types: Development (DEV), Delivery (DEL) and QA. The number of environments is limited per type, and the limit is shown in Build Place under settings, Environments Quota. Additional environments are ordered from IFS, which means an additional cost and a sales process, so count them in the project budget and the plan before the layout is fixed. Because these are users' answers, confirm the environment types, the quota and the price against your own agreement and the release you run.

On infrastructure that the customer runs, the labels differ and the setup is the customer's own, so the questions in the next sections are answered by your IT team and not by a request to IFS. The principle that non-production systems sit apart from production applies in both models.

A clone, or refresh, replaces the data and the configuration of a target environment with a copy of a source environment, typically production into test. The mechanics are not something I will describe screen by screen, because I did not find a procedure published by IFS, and the steps depend on the hosting model and the agreement. What I can describe is what each refresh has needed in the projects I run, and what you should ask IFS or your own IT team to confirm in writing before the first one.

• The target is unavailable while it is overwritten. Plan the window and tell the testers, because a refresh that starts at the wrong hour stops a test day.
• Source and target must be at the same release and the same installed content. A copy of production into a test system that already took a newer update will either be refused or give you a system that behaves differently from production.
• Settings that belong to the environment, not to the business, are overwritten too. Integration endpoints, credentials for third-party systems, message routing and system parameters come across from the source. Export or record them in the target before the refresh and reapply them after it.
• Anything built only in the target is lost. A configuration change made in test and never moved to the source disappears with the overwrite, so move or record it first.
• Request the refresh through the channel your agreement defines. For an IFS-managed environment that is a service request with IFS, and the lead time is a question for IFS, not a number I can give you.

Configuration should travel between environments through a controlled transfer and not by retyping it. Which mechanism applies depends on the release and on what kind of change it is, so settle it in the Test Strategy and test it once with a harmless change before you depend on it.

Refresh the test environment before a test cycle starts and not on a calendar, because the date that matters is the one printed on the test result. A refresh just before acceptance gives the testers data that looks like the business. A refresh in the middle of a cycle destroys the evidence collected so far and makes earlier results unrepeatable.

• Before each acceptance cycle: refresh, run the post-clone checklist, freeze configuration, record the date in the test script.
• Before the cutover rehearsal: refresh from the most recent production state the project can use, so that the rehearsal meets realistic volumes and master data.
• Never during a cycle: if a defect needs fresh data, create that data in the environment and note it, or stop the cycle and restart it deliberately.
• After a release update of production: bring the test systems to the same level before the next cycle. The Update Strategy template (IDK-23) covers the update side, and the question of when to test updates is covered in Service Update vs Release Update on the consulting site.

The SAT/ORT Test Script and Sign-off template (IDK-18) carries the field that makes this auditable: the environment used, its last refresh date and the source of the refresh. Without those three values a signed test says only that something passed somewhere.

After a copy from production, a test system still holds production addresses and users, so it can act on the outside world until each of those is switched off or redirected. I run the following checks in order and record the result before anyone is told the system is ready.

A read-only monitoring account is a good first thing to create on the non-production system. If you plan to run the SCM Automation Pack, the integration account can be set up on a test environment first, and the first week after installation runs without sending any message, so you see what the system would send before anyone receives it. Nothing is installed in your IFS, so a release update leaves nothing of ours for you to retest; compatibility with the new release is checked on our side under the subscription.

A copy of production in a test environment is still personal data, and UK GDPR applies to it in the same way as to the live system. The articles to read are the data protection principles in Article 5(1), data minimisation in point (c) and storage limitation in point (e), data protection by design in Article 25, and security of processing in Article 32. The regulation does not contain the word "masking". What it asks is that you hold only the personal data you need for the purpose, keep it no longer than needed and protect it appropriately, which for a test copy usually leads to masking or pseudonymisation, or to loading a reduced data set.

In practice I ask three questions about every non-production system:

• What personal data does the copy contain, such as employee records, supplier bank details, contact persons at customers and suppliers, and user names in logs and audit trails?
• Does the test purpose need those values, or only data of the right shape? A purchase-order flow test needs realistic structure and volume, not real bank account numbers or private addresses.
• Who can open the environment, from where, and is that list shorter than the list for production or at least no longer?

ISO/IEC 27001:2022 treats the same topic as a control, which is how it often reaches a project: Annex A 8.31 asks for separation of development, test and production environments and 8.33 asks for test information to be selected, protected and managed. An auditor who reads your Test Strategy will look for both.

Whether your IFS release offers a built-in function to anonymise data in a copy is a question I have not confirmed for this article, so I do not claim one. Ask IFS, and if there is none, agree a masking step in the project, run by the party that owns the data, before testers get access. This is a description of the legal text and of my practice, not legal advice. Your data protection officer or legal adviser decides what is required for your data. The ICO publishes guidance on UK GDPR that your adviser will use.

Review the layout by writing one line per environment: purpose, owner, release level, last refresh date, source of that refresh and who has access. A line that cannot be filled in is a finding. Doing this once before the acceptance cycle takes less time than explaining afterwards why a result cannot be reproduced.

If you want a second pair of eyes on the layout and the refresh plan, that is a 30-minute technical call with the person who would do the review. For test practice in general, see IFS Testing on the consulting site.

Book a 30-min technical call See the SAT/ORT test script template

• UK GDPR (retained Regulation (EU) 2016/679), Articles 5, 25 and 32, legislation.gov.uk
• UK GDPR guidance and resources, Information Commissioner's Office
• ISO/IEC 27001:2022, Annex A controls 8.31 and 8.33 (control numbers only, the text of the standard is not quoted)
• IFS Community thread: IFS Build Place environments (users' answers, not IFS documentation)

The Build Place description comes from the community thread above and is not documentation. Descriptions of clone and refresh behaviour come from project practice, not from a specific IFS documentation page, and they vary with hosting model, release and agreement. Check your agreement and the IFS documentation for the release you run before relying on any of it.

Dariusz Myśliwiec: 18 years hands-on with IFS, today on IFS Cloud. IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally. You talk to the consultant who builds it, not a sales layer.

Selected clients from my IFS work: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.