CHAI™ enables Enterprise IT to modernize their applications with minimum investment and maximum advantage. CHAI™ is industry’s first Automated Refactoring and Automated Containerization solution.
CHAI™ Vault is a secured service. This service stores the sensitive data such as credentials in an encrypted form. The cipher used is aes-256-cbc. The Vault facilitates management and usage of sensitive data. Vault enables credential to be consumed in various workflows available within CHAI™.
7. What different form-factors CHAI™ is available in?¶
Answer:
CHAI™ is available in TWO (2) form-factors. It can be registered and subscribed to use as Software as a Service (SaaS) model of cloud as well as a virtual appliance.
8. Which Operating Systems CHAI™ supports for application refactoring?¶
Answer:
Various variants of Linux and Windows Operating Systems are supported.
For more details, please refer Support Matrix in the Reference section: link
Windows 2012 R2, Windows 2016, Windows 2022 Servers.
For more details, please refer Support Matrix in the Reference section: link
10. Does CHAI™ support windows machine in domain?¶
Answer:
Yes, it supports & uses Kerberos Authentication method for the machine in Domain.
11. Does CHAI™ support both bit machines 32 bit,64 bit?¶
Answer:
Yes, It supports for both 32 bit & 64 bit Machines
12. What types of migration do you automate for the 6R’s?¶
Answer:
Out of the box, we currently automate Rehost and Refactor of Services.
We do Windows->Linux replatform for Weblogic and Websphere. Other variations in progress.
13. What kinds of applications can you Discover and Transform?¶
Answer:
We support commonly used Linux based applications, written in any software language. We also Discover and Transform ASP.NET and/or IIS Server based applications. We currently don’t have support for COBOL and mainframes.
14. What about COTS applications, can you transform them as well?¶
Answer:
Technically we can transform any COTS software. However, there may be support related issues from ISV. We need ISVs buy-in. We have worked with ISVs in the past to provide containerization support for their product line and would be happy to work with you and your COTS provider to add support for the COTS app which can also be transformed (rehost or refactor). Please send us an e-mail to isvsupport@cloudhedge.io with subject Cloud/Container migration in the subject line.
No, we discover the application and host at the network and services level.
16. user are asking for read-only SSH access to Discover and Transform apps - what if I don’t give you SSH access?¶
Answer:
The discover can't be executed.
17. Why should we containerize applications, we are already on cloud? What are the benefits?¶
Answer:
Have you refactored the code before moving to cloud or have you lifted and shifted applications to cloud. In either case, containerizing an application helps you reduce cloud billing, makes your application portable, secure, and scalable.
Containers have a smaller footprint and hence lesser compute cost.
Enables portability, including deployment of apps on a hybrid environment.
Enables you to scale a particular workload/ service instead of scaling the entire application
Application isolation allows you to improve security by setting each application’s major process apart from one another in separate containers.
18. Can we leverage CHAI™ Discover and Transform tools only?¶
Answer:
Yes, We can enable you to leverage just Discover and Transform tools.
19. What are the benefits of leveraging only Cruize?¶
Answer:
We automate your DevOps process and empower Developers to perform majority of software development lifecycle events that need environment provisioning/de-provisioning. The models we have developed for application environments help in reducing dependency on Ops or release engineering team. It significantly reduces your cost of high priced DevOps consultant and / or release engineer. Also, managing Kubernetes is provided as a feature of the Cruize.
20. Can we deploy our containerized apps on a pre-existing Kubernetes clusters?¶
Answer:
Yes, we have an option for you to bring your own cluster (BYOC). This option is only available for Kubernetes clusters. Currently, we do not support enabling existing Openshift clusters.
21. Does your Discover tool identify if the application is cloud ready or not?¶
Answer:
Yes, service level discovery and by identifying dependencies, allows us to discover potential issues from an application’s cloud readiness perspective, however for definitive conclusion, we will most probably need access to your source code. It will also need additional efforts to come to a conclusion. userr own developers or our SI partners can enable it to be cloud ready based on the inputs from Discover tool.
22. How much time will it take to migrate a simple application deployed across 1 or 2 nodes?¶
Answer:
Discovery to Deployment should not take more than 2 to 3 business days. (assuming all the required data and infra is available)
23. Can the dependency within the processes already detected identified intelligently/automatically by the tool? And subsequently reflected in the docker images that are created.¶
Answer:
Yes, it does this currently and includes all identified dependencies in the Docker images that are created. Perhaps, you should elaborate and clear my confusion.
24. How are the encrypted files (configs etc for the application) treated by the tool? How do they get migrated?¶
Answer:
Our ability to detect/analyze the hard-coding etc could be limited if the files are non-readable outside the application. However, it will get migrated.
Currently the cron jobs are not containerized. However in the future release it may be supported.
26. Can my Cloud Vault credentials be used with CH?¶
Answer:
NO. They are exclusively used only for Cruize tasks as needed.
27. Would my existing TLS certificates work after transform?¶
Answer:
In principle yes and no based on your environment. However this feature will be available in next releases.
28. What tools does CHAI™ install on my system? Are they cleaned up?¶
Answer:
CHAI™ installs a proprietry discovery tool on the host to be discovered. The binaries are not removed after the discovery as the same set of binaries are required during the transform phase.
29. How can my servers in the datacenter be accessed by CH SAAS portal?¶
Answer:
CH Saas portal connects to hosts over network ( ssh ). One need to open up the external firewall and allow the port forwarding for CH Saas portal to reach to the hosts on internal network.
30. Can I use username and password for SSH authentication instead of SSH key?¶
Answer:
Yes. One can use ssh keys or username/password to connect to host.
31. Can I bulk import my Datacenter systems details?¶
Answer:
Yes. One can use chcli to provision the bulk hosts.
33. Can copying of SSH keys and adding sudoers entries be automated across all the candidates in scope of discovery?¶
Answer:
Yes. We can use ansible to automate that.
34. In discovery-step2 (x-ray) we observe that the processes are restarting while inserting the probe. Is there a way we can avoid it?¶
Answer:
We are adding functionality wherever possible to not require restart.
The restart does have significant advantages & provides us the unique ability to learn dynamic behavior hence it's recommended to be applied to non-production environments."
35. Currently the discovery is detecting the processes of OS/servers. Is there a way discovery can intelligently identify the applications that are running within the server? E.g. discovering the library application automatically by the tool.¶
Answer:
CH does detect the libraries used by the application as part of the library dependencies.
36. The external dependencies (like DB/SMTP servers/other apps etc) can be identified by the tool? In the discovery we did entered the mysql instance dependency manually.¶
Answer:
Yes, it can be. It does not have to added as part of the wave. We do have ability to detect external service/host dependencies as well.
37. Can the tool detect the stopped processes? e.g. The jboss service that was stopped was not detected in the first scan. We had to start it before it was reflected in the scan report.¶
Answer:
Currently it does not, however our tool can be enhanced to do that. Since the servers we ask to be X-rayed are generally non-production/replica of production, we have found that the services that people need to be running for working application are running and are detected.
38. What is the outcome of the scan if there are any scheduled jobs (like cron jobs etc) hosted on the source? How does the tool treat them, if they are not running?¶
Answer:
We do detect the cron jobs. It will be available as part of the next release by middle of October.
39. App and if not app but part of infra can be containerized or not ?¶
Answer:
App can be containerized.
Infra components migration is best handled by Pro Serv.
40. Architecturally which application components can be and can not be transformed ?¶
Answer:
As such there isn't restriction on containerizing specific components. The effort required to get the container working may vary.
41. Architecturally which infrastructure components can be and can not be transformed ?¶
Answer:
Infrastructure wise, we believe the components are not required to be containerized.
42. Which platform softwares and tools can be transformed ?¶
Answer:
Apache HTTP
Nginx
IIS
Tomcat
JBoss
Oracle WebLogic
IBM Websphere
Jenkins
Redmine
Alfresco
Odoo
43. Which programming languages and tools can be transformed ?¶
Answer:
.NET framework applications deployed on IIS are transformed today.
On Linux, there isn't restriction on the basis of programming language."
44. How it works for components in single VM Vs separate VMs and what is suggested from analysis with respect to separating different components into separate containers, whether it considers network segmentation (DMZ Vs Internal)?¶
Answer:
Networking connectivity enablement across networks is out of scope of CHAI™ tool. Can be accomplished using Pro Serv.
45. How and what compliance aspects are addressed ?¶
Answer:
We do not have compliance certification for PCI/DSS or HIPAA.
46. How is data on additional file systems/disks handled ? and How are OS user and file ownerships handled ?¶
Answer:
Data on additional mounted file system / disks detection is not implemented however, we are planning it.
As mentioned in prerequisite ownership should be provided to OS user.
47. Is there any table or chart for estimated time for Discover / Transform specific applications ?¶
Answer:
This is dependent on the application size and regression test suite and whether the application testing is automated or manual.
In addition to the time taken for testing, for complex applications/processes, it takes about 1-2 hours. For medium/low complex processes, the amount of time taken will be less than 1 hour.
48. Why there is "Sleeping" status for all services in recommendation report?¶
Answer:
This is updated in the latest release of CHAI™. Sleeping status will be removed to filter out processes that are running only. All discovered, filtered processes will be listed as valid.
No, we decided to focus on a bigger problem i.e. migrating an application. There are a lot of data migration tools that can be leveraged by your team or our SI partner could also help migrate data from on-premise to Cloud. If you need CHAI™ to recommend an approach, please get in touch with proserv@cloudhedge.io
50. How and where can I increase my session timeout?¶
Answer:
Go to Settings > Configuration > User Preferences. Under "Logout session time", enter the required number and select the unit (hour/day/month/year), then save the changes. Default session time is 1 hour.
You need to logout once and login again for the updated session time to take effect.
For detailed steps with images, please refer link.
51. Why can't RVTools based discovery be online or live?¶
Answer:
RVTools discovery is based on a point-in-time inventory export of your VMware environment (VMs, hosts, configuration, utilization, etc.) which is exported as a csv and then imported into CHAI™. Since it works off an already exported snapshot and not an active agent/probe running on the host, it cannot provide live or continuous discovery.
For live/continuous discovery, CHAI™'s agent based Discover (x-ray) on the actual hosts should be used, as it interacts with the host in real time.
52. Which file formats are supported for bulk import in CHAI™? Can I use semicolon or other delimiters instead of comma?¶
Answer:
CHAI™ only supports comma separated values (.csv) files for bulk import (e.g. bulk host import, RVTools/VMware data import).
Files using semicolon (;), tab, or any other delimiter are not supported and will either fail to import or read the data incorrectly. Please ensure the file is saved/exported strictly with comma (,) as the delimiter before uploading it to CHAI™.
The bulk import CSV file must not contain any header row. For bulk host import, each row must contain the following, in the same order: Project Name, OS, Host name or IP, Alias, Username, Port, Connection Type, Vault Name.
The Project Name must be unique across the file, and the Vault Name referenced must already exist in the CHAI™ Vault.
For the complete CSV format and field descriptions, please refer link.
53. My bulk import file is failing/reading incorrectly, could this be a localization issue?¶
Answer:
Yes. Depending on your system's regional/localization settings, some spreadsheet applications (e.g. Excel on certain European locales) export CSV files using semicolon (;) instead of comma (,) as the default delimiter. CHAI™ bulk import only accepts comma separated files.
Please check the delimiter used in your exported file and re-save/export it as a comma (,) separated CSV before uploading it to CHAI™.
54. What is Bulk Action, and how is it different from running DART operations one server at a time?¶
Answer:
Historically, DART operations had to be triggered one server at a time — select a server, run Check Connection, then move to the next. On a project with hundreds of servers, that is slow and repetitive.
Bulk Action lets you trigger any DART operation on all available servers in a project at once. One click fans the operation out across every node, automatically splitting the work into managed batches and tracking each batch to completion.
Bulk Action covers DART/Discovery operations only, exposed in the order you'd normally run them: Check Connection, Prerequisites, Discover, Start/Stop Networks.
Transform/containerization operations, including X-Ray, are not covered — X-Ray belongs to the Transform phase.
56. Can I run Bulk Action on a specific subset of servers instead of the whole project?¶
Answer:
No. Bulk Action always targets all available nodes of the current project, not a hand-picked subset.
To run an operation on just a few specific servers, use the existing per-server flow — select those servers and run the operation on them directly.
57. What is required before I can use Bulk Action?¶
Answer:
Servers must first be added to the project, either via Add Host or a CSV import of multiple hosts (see FAQ #52 for the bulk import CSV format).
Each Bulk Action stage feeds the next — for example, Discover only runs on servers that already passed the earlier Check Connection and Prerequisites stages.
58. How are servers grouped into batches when I trigger a Bulk Action?¶
Answer:
Two rules drive batching. First, batch size — controlled by "bulk job batch size" (default 25 servers per batch).
Second, operating system never mixes — Windows and Linux servers are never placed in the same batch. The system first collects the node data, then segregates by OS and applies the batch-size limit within each OS group.
Later stages narrow automatically: if only 4 servers pass Check Connection, the subsequent Discover job builds its batches from just those 4 available nodes.
Batches run sequentially; servers within a batch are processed together. Batch size and poll interval govern the timing.
60. Can I configure the batch size, poll interval, and timeouts used by Bulk Action?¶
Answer:
Yes. Under inside project from left sidebar, click on Project (Project Settings) → Configurations → Bulk Action Configuration, every parameter is configurable per project and ships with sensible defaults tuned from real-world runs.
bulk job batch size (default 25): max servers per batch, per OS group.
bulk job poll interval (default 120s): how long a batch waits for a response before the job moves on / auto-closes if nothing started at the backend.
timeout – check connection (default 600s/10 min): overall time budget for the Check Connection stage.
timeout – prerequisite checks (default ~20 min): budget for pre-checks, which can be slower.
timeout – discover (longer): discovery can take time, so its budget is raised.
timeout – network start/stop (default 900s/15 min): networks across many servers typically need ~7 min; this gives headroom.
Longer timeouts exist because some stages, especially Windows discovery, legitimately take longer.
61. What happens if a Bulk Action operation doesn't actually start at the backend?¶
Answer:
The bulk job poll interval protects against a hung job — if you trigger an operation and nothing starts at the backend, that batch is closed automatically after the poll interval (default 120s) with no response, and the job proceeds rather than hanging forever.
62. How can I track the progress and history of a Bulk Action run?¶
Answer:
Use View History from the Bulk Action menu to open the bulk-operation history. Each run produces a Job ID with the action item (e.g. Check Connection, Prerequisite, Discover) and overall process status — In Progress or Completed.
It also shows total batches, plus start and completion times, and a per-batch drill-down of which servers were in each batch and their individual results (green = succeeded/available, failed = unreachable or errored).
63. Can I cancel a batch once a Bulk Action job has started?¶
Answer:
A batch that has already started can't be stopped. However, you can cancel a pending (not-yet-started) batch — useful if you spot a problem with the servers in an upcoming group.
Cancelling one batch skips only that batch; the job continues with the rest.
64. Why does a Bulk Action job/batch show "Completed" while some hosts are still "In Progress"?¶
Answer:
Batch/Job status reflects whether the operation was successfully dispatched and acknowledged across the servers — not whether every downstream background task has fully finished. A batch can read Completed while the target machine is still collecting data (data collection is heavier on Windows).
Per-server status is separate: green means that server responded/is available; failed means it was unreachable or returned no expected data. Failures in one batch don't block the next batch.
Known gap (planned fix): if a batch completes but a few servers within it failed, it currently just shows Completed. A more descriptive message — e.g. "batch completed, N servers failed" — is planned as a lower-priority enhancement.
65. Where can I check logs if a Bulk Action operation fails?¶
Answer:
Check the container/service logs, which are also surfaced via the dashboard log option. Richer in-dashboard failure visibility is on the roadmap.
66. Does Bulk Action include X-Ray or other containerization/Transform steps?¶
Answer:
No. Bulk Action is Discovery-only and covers Check Connection, Prerequisites, Discover, and Start/Stop Networks.
X-Ray and other Transform/containerization steps are out of scope for Bulk Action.